idnits 2.17.1 draft-rosen-ecrit-lost-planned-changes-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 -- The document date (February 14, 2014) is 3724 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ecrit B. Rosen 3 Internet-Draft Neustar 4 Intended status: Standards Track February 14, 2014 5 Expires: August 18, 2014 7 Validation of Locations Around a Planned Change 8 draft-rosen-ecrit-lost-planned-changes-01 10 Abstract 12 This document defines an extension to LoST (RFC5222) that allows a 13 planned change to the data in the LoST server to occur. Records that 14 previously were valid will become invalid at a date in the future, 15 and new locations will become valid after the date. The extension 16 adds two elements to the request: a URI to be used to 17 inform the LIS that previously valid locations will be invalid after 18 the planned change date, and add a date which requests the server to 19 perform validation as of the date specified. It also adds a TTL 20 element to the response, which informs all queriers the current 21 expected lifetime of the validation. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 18, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions used in this document . . . . . . . . . . . . . . 3 59 3. element . . . . . . . . . . . . . . . . . . . 4 60 4. object . . . . . . . . . . . . . . . . 4 61 5. TTL in Response . . . . . . . . . . . . . . . . . . . . . . . 4 62 6. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 5 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 8.1. Relax NG Schema Registration . . . . . . . . . . . . . . 8 66 8.2. LoST Namespace Registration . . . . . . . . . . . . . . . 8 67 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 This document describes an update to the LoST protocol [RFC5222] 72 which allows a request to add a URI and a date to be 73 used with planned changes to the underlying location information in 74 the server which is used by the validation function. The URI is 75 retained by the LoST server, associated with the data record that was 76 validated, and used to notify the LIS (the LoST client) when a 77 location which was previously valid will become invalid. The date is 78 used by the client to ask the server to perform validation as of a 79 future date. The lt;findserviceResponse> is extended to provide a 80 TTL for validation, after which the client should revalidate the 81 location. 83 Validation of civic locations involves dealing with data that changes 84 over time. A typical example is a portion of a county or province 85 that was not part of a municipality is "annexed" to a municipality. 86 Prior to the change, the content of the PIDF A3 element would be 87 blank, or represent some other value and after the change would be 88 the municipality that annexed that part of the county/province. This 89 kind of annexation has an effectivity date (typically 00:00 on some 90 date). 92 Records in a LIS must change around these kinds of events. The old 93 record must be discarded, and a new, validated record must be loaded 94 into the LIS. It is often difficult for the LIS operator to know 95 that records must be changed. There are other circumstances where 96 locations that were previously valid become invalid. As RFC5222 97 defines validation, the only way for a LIS to discover such changes 98 was to periodically revalidate its entire database. Of course, this 99 would not facilitate timely changes, and also adds significant load 100 to the LoST server. Even if re-validation is contemplated, the 101 server has no mechanism to control, or even suggest the time period 102 for revalidation 104 This extension allows the client to provide a stable URI that is 105 retained by the server associated with the location provided that the 106 location information in the request was valid. In the event of a 107 planned change, or any other circumstance where the LI becomes 108 invalid, the server sends a notification to the URI informing it of a 109 change. The notification contains the date and time when the LI 110 becomes invalid. 112 Ideally, the LIS will prepare a new record, to be inserted in its 113 active database, that becomes valid at the precise planned event date 114 and time, at which point it would also delete the old record. 115 However, the new record has to be valid, and the LIS would like to 116 validate it prior to the planned change event. If it requests 117 validation before the planned event, the server (without this 118 extension) would inform the client that the location was invalid. 119 This extension includes an optional "asOf" date and time in the 120 request that allows the LoST server to provide validation as of the 121 date and time specified, as opposed to the "as of now" implied in the 122 current LoST protocol. 124 When it is not practical or advisable for the LIS to maintain stable 125 URIs for all of its records, periodic revalidation can be used to 126 maintain the data in the LIS. However, the server should be able to 127 control the rate of such revalidation. For this purpose, a new TTL 128 element is included in the lt;findserviceResponse> when validation is 129 requested. 131 2. Conventions used in this document 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 "Server" in this document refers to the LoST server and "Client" is 138 the LoST client, even when the server is performing an operation on 139 the client. 141 3. element 143 This document defines a new element to called 144 'plannedChange'. This element contains two attributes: 'uri' and 145 'asOf'. The 'uri' attribute MUST be a URI with a scheme of https. 146 The URI will be stored by the server against the location in the 147 request for subsequent use with the notification function defined 148 below. To minimize storage requirements of at the server, the length 149 of the URI MUST be less than 256 bytes. Each client of the server 150 may only store one URI against a location, where "location" is 151 defined by policy at the server, since a given unique location may 152 have many combinations of LI elements that resolve to the same 153 location. If the server receives a 'uri' for the same location from 154 the same client, the URI in the request replaces the URI it 155 previously retained. Policy at the server may limit how many uris it 156 retains for a given location. A new warning is defined below to be 157 used to indicate that the URI has not been stored. 159 The 'asOf' attribute contains a date and time. The server will 160 validate the location in the request as of the date specified, taking 161 into account planned changes. This allows the client to verify that 162 it can make changes in the LIS commensurate with changes in the LoST 163 server by validating locations in advance of a change. 165 4. object 167 When the server needs to invalidate a location where the client 168 provided a URI in , the server sends 169 to the URI previously provided. This is the 170 notice from the server to the client that the location may be invalid 171 and should be revalidated. contains an asOf 172 attribute that specifies when the location may become invalid. If 173 the date/time in asOf is earlier than the time the 174 was sent, the location may already be invalid 175 and the LIS should take immediate action. 177 5. TTL in Response 179 A new 'ttl' element is added to the lt;findserviceResponse>. The ttl 180 element contains a date and time after which the client may wish to 181 revalidate the location at the server. This element MAY be added by 182 the server if validation is requested in the response. The form of 183 the element is the 'expires' pattern, which allows explicit 'No 184 Cache' and 'No Expiration' values to be returned. 'No Cache' has no 185 meaning and MUST NOT be returned in TTL. 'No Expiration' means the 186 server does not have any suggested revalidation period. 188 Selecting a revalidation interval is a complex balancing of 189 timeliness, server load, stability of the underlying data, and policy 190 of the LoST server. Too short, and load on the server may overwhelm 191 it. Too long and invalid data may persist in the server for too 192 long. The URI mechanism provides timely notice to coordinate 193 changes, but even with it, it is often advisable to revalidate data 194 eventually. 196 In areas that have little change in data, such as fully built out, 197 stable communities already part of a municipality, it may be 198 reasonable to set revalidation periods of 6 months or longer, 199 especially if the URI mechanism is widely deployed at both the server 200 and the clients. In areas that are quickly growing, 20-30 day 201 revalidation may be more appropriate even though such revalidation 202 would be the majority of the traffic on the LoST server. 204 When a planned change is made, typically the TTL for the affected 205 records is lowered, so that revalidation is forced soon after the 206 change is implemented. It is not advisable to set the expiration 207 precisely at the planned change time if a large number of records 208 will be changed, since that would cause a large spike in traffic at 209 the change time. Rather, the expiration time should have a random 210 additional time added to it to spread out the load. 212 6. Relax NG Schema 214 The Relax NG schema in [RFC5222] is modified to be: 216 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 217 default namespace ns1 = "urn:ietf:params:xml:ns:lost-plannedChange1" 219 ## 220 ## Extension to Location-to-Service Translation (LoST) Protocol 221 ## to support a planned change to location data 222 ## 223 ## plannedChange is used in the extensionPoint of 224 ## commonRequestPattern in a findService request 225 ## 226 ## locationInvalidated is used by the LoST server to notify a 227 ## LIS that a previously valid location may be (or will become) 228 ## invalid 229 ## 230 ## ttl is used in the extensionPoint of 231 ## commonResponsePattern in a findService response 232 ## 233 ## uriNotStored is a new warning to be used in a 234 ## exceptionContainer in the warnings element of a 235 ## findServiceResponse 236 ## 237 start = 238 plannedChange 239 | locationInvalidated 240 | uriNotStored 241 ## 242 ## plannedChange 243 ## 244 div { 245 plannedChange = 246 element plannedChange { 247 attribute uri { 248 xsd:anyURI }?, 249 attribute asOf { 250 xsd:dateTime }?, 251 extensionPoint+ 252 } 253 } 255 ## 256 ## locationInvalidated 257 ## 258 div { 259 locationInvalidated = 260 element locationInvalidated { 261 attribute asOf { 262 xsd:dateTime }?, 263 extensionPoint+ 264 } 265 } 267 ## 268 ## ttl 269 ## 270 div { 271 ttl = 272 element ttl { 273 expires, 274 extensionPoint+ 275 } 276 } 278 ## 279 ## uriNotStored 280 ## 281 div { 282 uriNotStored = 283 element uriNotStored { basicException } 285 } 287 ## 288 ## Patterns for inclusion of elements from schemas in 289 ## other namespaces. 290 ## 291 div { 293 ## 294 ## Any element not in the LoST namespace. 295 ## 296 notLostChange = element * - (ns1:* | ns1:*) { anyElement } 298 ## 299 ## A wildcard pattern for including any element 300 ## from any other namespace. 301 ## 302 anyElement = 303 (element * { anyElement } 304 | attribute * { text } 305 | text)* 307 ## 308 ## A point where future extensions 309 ## (elements from other namespaces) 310 ## can be added. 311 ## 312 extensionPoint = notLostChanged* 313 } 315 7. Security Considerations 317 As an extension to LoST, this document inherits the security issues 318 raised in [RFC5222]. The server could be tricked into storing a 319 malicious URI which, when sent the locationInvalidated object could 320 trigger something untoward. The server MUST NOT accept any data from 321 the client in response to POSTing the locationInvalidated. 323 The server is subject to abuse by clients because it is being asked 324 to store something and may need to send data to an uncontrolled URI. 325 Clients could request many URIs for the same location for example. 326 The server MUST have policy that limits use of this mechanism by a 327 given client. If the policy is exceeded, the server returns the 328 uriNotStored warning. The server MUST validate that the content of 329 the uri sent is syntactically valid and meets the 256 byte limit. 330 When sending the locationInvalidated object to the uri stored, the 331 server MUST protect itself against common http vulnerabilities. 333 The mutual authentication between client and server when is 334 RECOMMENDED for both the initial findService operation that requests 335 storing the uri and the sending of the locationInvalidated object. 336 The server should be well known to the client, and its credential can 337 be learned in a reliable way. For example, a public safety system 338 operating the LoST server may have a credential traceable to a well 339 known Certificate Authority known to provide credentials for public 340 safety agencies. Many of the clients will be operated by local ISPs 341 or other service providers where the server operator can reasonably 342 obtain a good credential to use for the URI. Where the server does 343 not recognize the client, its policy MAY limit the use of this 344 feature beyond what it would limit a client it recognized. 346 8. IANA Considerations 348 8.1. Relax NG Schema Registration 350 URI: urn:ietf:params:xml:schema:lost-planedChange1 352 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 353 (br@brianrosen.net). 355 Relax NG Schema: The Relax NG schema to be registered is contained 356 in Section 5. Its first line is 358 default namespace = "urn:ietf:params:xml:ns:lost-PlannedChange1 360 and its last line is 362 } 364 8.2. LoST Namespace Registration 365 URI: urn:ietf:params:xml:ns:lost-plannedChange1 367 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 368 (br@brianrosen.net). 370 XML: 372 BEGIN 373 374 376 377 378 380 LoST Planned Change Namespace 381 382 383

Namespace for LoST Planned Change extension

384

urn:ietf:params:xml:ns:lost-plannedChange1

385

See 386 RFC????.

387 388 389 END 391 9. Normative References 393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 394 Requirement Levels", BCP 14, RFC 2119, March 1997. 396 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 397 Tschofenig, "LoST: A Location-to-Service Translation 398 Protocol", RFC 5222, August 2008. 400 Author's Address 402 Brian Rosen 403 Neustar 404 470 Conrad Dr 405 Mars, PA 16046 406 US 408 EMail: br@brianrosen.net