idnits 2.17.1 draft-schulzrinne-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 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 378. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 26, 2006) is 6360 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 (-10) exists of draft-ietf-ecrit-lost-02 == Outdated reference: A later version (-04) exists of draft-ietf-ecrit-mapping-arch-00 Summary: 3 errors (**), 0 flaws (~~), 4 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 November 26, 2006 5 Expires: May 30, 2007 7 Synchronizing Location-to-Service Translation (LoST) Servers 8 draft-schulzrinne-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 May 30, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 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 . . . . . . . 3 51 4. Synchronizing Mapping Stores via and 52 . . . . . . . . . . . . . . . . . . . . 6 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 55 6.1. LoST Synchronization Namespace Registration . . . . . . . 8 56 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 57 8. RelaxNG . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 60 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 Intellectual Property and Copyright Statements . . . . . . . . . . 10 64 1. Introduction 66 The LoST (Location-to-Service Translation) protocol [2] maps 67 geographic locations to service URLs. As specified in the LoST 68 architecture description [3], there are a variety of LoST servers 69 that cooperate to provide a global, scalable and resilient mapping 70 service. The LoST protocol specification only describes the protocol 71 used for individual seeker-originated queries. This document adds 72 LoST operations that allow forest guides, resolver clusters and 73 authoritative servers to synchronize their database of mappings. 75 In the LoST architecture, servers can peer, i.e., have an on-going 76 data exchange relationship. Peering relationships are set up 77 manually, based on local policies. A server can peer with any number 78 of other servers. Forest guides peer with other forest guides; 79 resolvers peer with forest guides and other resolvers (in the same 80 cluster); authoritative mapping servers peer with forest guides and 81 other authoritative servers, either in the same cluster or above or 82 below them in the tree. If the type of LoST role does not matter, we 83 refer to LoST protocol participants as LoST nodes. 85 Authoritative mapping servers push coverage regions "up" the tree, 86 i.e., from child nodes to parent nodes. The child informs the parent 87 of the geospatial or civic region that it covers. The service URL 88 contains the LoST URL of the child node. 90 This extension defines two new requests, and 91 , that allow peering servers to exchange 92 mappings. These requests are used for all peering relationships and 93 always contain mapping entries, but naturally the content of the data 94 exchanged differs. 96 2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [1]. 102 This document reuses terminology introduced by the mapping 103 architecture document [3]. 105 3. Distributing Mappings via 107 When a LoST node obtains new information that is of interest to its 108 peers, it pushes the new mappings to its peers. This information 109 might arrive through non-LoST means, such as a manual addition to the 110 local mappings database, or through another LoST node, via a 111 request or a described later. 112 Mappings in that request replace existing mappings with the same 'id' 113 parameter and a more recent 'created' parameter. (Enforcing the 114 latter avoids that a node that wakes up injects outdated information 115 into the system.) 117 Each peer keeps track of which peer it has exchanged which mapping 118 elements with. Mapping elements are identified by the 'id' and 'tag' 119 parameters. A mapping is considered the same if these two attributes 120 match. Nodes never push the same information to the same peer twice. 122 To delete a mapping, the content of the mapping is left empty. The 123 node can delete the mapping from its internal mapping database, but 124 has to remember which peers it has distributed this update to. The 125 mapping is identified only by the 'sourceId' and 'source' parameters; 126 the other parameters are ignored if present. In other words, the 127 delete operation affects all versions of a mapping. 129 The response to is . It 130 only contains elements if there is an error condition. Only 131 the .... errors are defined (TBD). 133 If the set of nodes that are synchronizing their data does not form a 134 tree, it is possible that the same information arrives through 135 several other nodes. This is unavoidable, but generally only imposes 136 a modest overhead. (It would be possible to create a spanning tree 137 in the same fashion as IP multicast, but the complexity does not seem 138 warranted, giving the relatively low volume of data.) 140 An example is shown in Figure 1. In the example, the last mapping, 141 with source lost:nj.us.example and mapping ID 'englewood', is being 142 removed. 144 145 146 147 150 151 Leonia Police Department 152 153 urn:service:sos.police 154 156 158 US 159 NJ 160 Leonia 161 07605 162 163 164 sip:police@leonianj.example.org 165 911 166 168 173 174 New York City Police Department 175 176 urn:service:sos.police 177 178 179 180 181 37.775 -122.4194 182 37.555 -122.4194 183 37.555 -122.4264 184 37.775 -122.4264 185 37.775 -122.4194 186 187 188 189 190 sip:nypd@example.com 191 xmpp:nypd@example.com 192 911 193 195 197 198 200 201 202 203 Figure 1: Example pushMappingsRequest and pushMappingsResponse 205 4. Synchronizing Mapping Stores via and 206 208 While the request allows new mappings to 209 propagate, it does not allow a newly-arriving node to acquire all 210 mappings maintained by another node. Thus, and 211 are used to synchronize two mapping stores. A 212 LoST node wanting to synchronize its mapping store with another node 213 issues a , containing an enumeration of the 214 current mapping source identifiers, tags and versions. The recipient 215 of the request compares that list to its own list of mappings. It 216 then returns an unordered set of mappings that are more recent than 217 the ones identified in the . It also returns any 218 mappings that it knows about that are not contained in the list at 219 all. Thus, a querier can get the complete listing of mappings by 220 omitting 'm' elements altogether. 222 An example request and response is shown in Figure 2 223 224 225 227 229 230 232 233 238 239 New York City Police Department 240 241 urn:service:sos.police 242 243 244 245 246 37.775 -122.4194 247 37.555 -122.4194 248 37.555 -122.4264 249 37.775 -122.4264 250 37.775 -122.4194 251 252 253 254 255 sip:nypd@ny.example.com 256 xmpp:nypd@example.com 257 911 258 259 260 262 Figure 2: Example getMappingsRequest and getMappingsResponse 264 5. Security Considerations 266 The LoST security considerations are discussed in [2]. The 267 operations described in this document involve mutually-trusting LoST 268 nodes. These nodes need to authenticate each other, using mechanisms 269 such as HTTP Digest, HTTP Basic over TLS or TLS client and server 270 certificates. Nodes implementing LoST MUST implement HTTP Basic 271 authentication over TLS and MAY implement other authentication 272 mechanisms. 274 6. IANA Considerations 276 6.1. LoST Synchronization Namespace Registration 278 URI: urn:ietf:params:xml:ns:lost1:sync 279 Registrant Contact: IETF ECRIT Working Group, Henning Schulzrinne 280 (hgs@cs.columbia.edu). 281 XML: 283 BEGIN 284 285 287 288 289 291 LoST Synchronization Namespace 292 293 294

Namespace for LoST server synchronization

295

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

296

See RFCXXXX 297 [NOTE TO IANA/RFC-EDITOR: 298 Please replace XXXX with the RFC number of this 299 specification.].

300 301 302 END 304 7. Acknowledgments 306 Your name here. 308 8. RelaxNG 310 TBD 312 9. References 313 9.1. Normative References 315 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 316 Levels", BCP 14, RFC 2119, March 1997. 318 [2] Hardie, T., "LoST: A Location-to-Service Translation Protocol", 319 draft-ietf-ecrit-lost-02 (work in progress), October 2006. 321 9.2. Informative References 323 [3] Schulzrinne, H., "Location-to-URL Mapping Architecture and 324 Framework", draft-ietf-ecrit-mapping-arch-00 (work in progress), 325 August 2006. 327 Author's Address 329 Henning Schulzrinne 330 Columbia University 331 Department of Computer Science 332 450 Computer Science Building 333 New York, NY 10027 334 US 336 Phone: +1 212 939 7004 337 Email: hgs+ecrit@cs.columbia.edu 338 URI: http://www.cs.columbia.edu 340 Full Copyright Statement 342 Copyright (C) The Internet Society (2006). 344 This document is subject to the rights, licenses and restrictions 345 contained in BCP 78, and except as set forth therein, the authors 346 retain all their rights. 348 This document and the information contained herein are provided on an 349 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 350 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 351 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 352 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 353 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 354 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 356 Intellectual Property 358 The IETF takes no position regarding the validity or scope of any 359 Intellectual Property Rights or other rights that might be claimed to 360 pertain to the implementation or use of the technology described in 361 this document or the extent to which any license under such rights 362 might or might not be available; nor does it represent that it has 363 made any independent effort to identify any such rights. Information 364 on the procedures with respect to rights in RFC documents can be 365 found in BCP 78 and BCP 79. 367 Copies of IPR disclosures made to the IETF Secretariat and any 368 assurances of licenses to be made available, or the result of an 369 attempt made to obtain a general license or permission for the use of 370 such proprietary rights by implementers or users of this 371 specification can be obtained from the IETF on-line IPR repository at 372 http://www.ietf.org/ipr. 374 The IETF invites any interested party to bring to its attention any 375 copyrights, patents or patent applications, or other proprietary 376 rights that may cover technology that may be required to implement 377 this standard. Please address the information to the IETF at 378 ietf-ipr@ietf.org. 380 Acknowledgment 382 Funding for the RFC Editor function is provided by the IETF 383 Administrative Support Activity (IASA).