idnits 2.17.1 draft-rosen-ecrit-lost-planned-changes-02.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 (July 20, 2015) is 3203 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 July 20, 2015 5 Expires: January 21, 2016 7 Validation of Locations Around a Planned Change 8 draft-rosen-ecrit-lost-planned-changes-02 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 January 21, 2016. 40 Copyright Notice 42 Copyright (c) 2015 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 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 This document describes an update to the LoST protocol [RFC5222] 73 which allows a request to add a URI and a date to be 74 used with planned changes to the underlying location information in 75 the server which is used by the validation function. The URI is 76 retained by the LoST server, associated with the data record that was 77 validated, and used to notify the LIS (the LoST client) when a 78 location which was previously valid will become invalid. The date is 79 used by the client to ask the server to perform validation as of a 80 future date. The lt;findserviceResponse> is extended to provide a 81 TTL for validation, after which the client should revalidate the 82 location. 84 Validation of civic locations involves dealing with data that changes 85 over time. A typical example is a portion of a county or province 86 that was not part of a municipality is "annexed" to a municipality. 87 Prior to the change, the content of the PIDF A3 element would be 88 blank, or represent some other value and after the change would be 89 the municipality that annexed that part of the county/province. This 90 kind of annexation has an effectivity date (typically 00:00 on some 91 date). 93 Records in a LIS must change around these kinds of events. The old 94 record must be discarded, and a new, validated record must be loaded 95 into the LIS. It is often difficult for the LIS operator to know 96 that records must be changed. There are other circumstances where 97 locations that were previously valid become invalid. As RFC5222 98 defines validation, the only way for a LIS to discover such changes 99 was to periodically revalidate its entire database. Of course, this 100 would not facilitate timely changes, and also adds significant load 101 to the LoST server. Even if re-validation is contemplated, the 102 server has no mechanism to control, or even suggest the time period 103 for revalidation 105 This extension allows the client to provide a stable URI that is 106 retained by the server associated with the location provided that the 107 location information in the request was valid. In the event of a 108 planned change, or any other circumstance where the LI becomes 109 invalid, the server sends a notification to the URI informing it of a 110 change. The notification contains the date and time when the LI 111 becomes invalid. 113 Ideally, the LIS will prepare a new record, to be inserted in its 114 active database, that becomes valid at the precise planned event date 115 and time, at which point it would also delete the old record. 116 However, the new record has to be valid, and the LIS would like to 117 validate it prior to the planned change event. If it requests 118 validation before the planned event, the server (without this 119 extension) would inform the client that the location was invalid. 120 This extension includes an optional "asOf" date and time in the 121 request that allows the LoST server to provide validation as of the 122 date and time specified, as opposed to the "as of now" implied in the 123 current LoST protocol. 125 When it is not practical or advisable for the LIS to maintain stable 126 URIs for all of its records, periodic revalidation can be used to 127 maintain the data in the LIS. However, the server should be able to 128 control the rate of such revalidation. For this purpose, a new TTL 129 element is included in the lt;findserviceResponse> when validation is 130 requested. 132 2. Conventions used in this document 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 "Server" in this document refers to the LoST server and "Client" is 139 the LoST client, even when the server is performing an operation on 140 the client. 142 3. element 144 This document defines a new element to called 145 'plannedChange'. This element contains two attributes: 'uri' and 146 'asOf'. The 'uri' attribute MUST be a URI with a scheme of https. 147 The URI will be stored by the server against the location in the 148 request for subsequent use with the notification function defined 149 below. To minimize storage requirements of at the server, the length 150 of the URI MUST be less than 256 bytes. Each client of the server 151 may only store one URI against a location, where "location" is 152 defined by policy at the server, since a given unique location may 153 have many combinations of LI elements that resolve to the same 154 location. If the server receives a 'uri' for the same location from 155 the same client, the URI in the request replaces the URI it 156 previously retained. Policy at the server may limit how many uris it 157 retains for a given location. A new warning is defined below to be 158 used to indicate that the URI has not been stored. 160 The 'asOf' attribute contains a date and time. The server will 161 validate the location in the request as of the date specified, taking 162 into account planned changes. This allows the client to verify that 163 it can make changes in the LIS commensurate with changes in the LoST 164 server by validating locations in advance of a change. 166 4. object 168 When the server needs to invalidate a location where the client 169 provided a URI in , the server sends 170 to the URI previously provided. This is the 171 notice from the server to the client that the location may be invalid 172 and should be revalidated. contains an asOf 173 attribute that specifies when the location may become invalid. If 174 the date/time in asOf is earlier than the time the 175 was sent, the location may already be invalid 176 and the LIS should take immediate action. 178 5. TTL in Response 180 A new 'ttl' element is added to the lt;findserviceResponse>. The ttl 181 element contains a date and time after which the client may wish to 182 revalidate the location at the server. This element MAY be added by 183 the server if validation is requested in the response. The form of 184 the element is the 'expires' pattern, which allows explicit 'No 185 Cache' and 'No Expiration' values to be returned. 'No Cache' has no 186 meaning and MUST NOT be returned in TTL. 'No Expiration' means the 187 server does not have any suggested revalidation period. 189 Selecting a revalidation interval is a complex balancing of 190 timeliness, server load, stability of the underlying data, and policy 191 of the LoST server. Too short, and load on the server may overwhelm 192 it. Too long and invalid data may persist in the server for too 193 long. The URI mechanism provides timely notice to coordinate 194 changes, but even with it, it is often advisable to revalidate data 195 eventually. 197 In areas that have little change in data, such as fully built out, 198 stable communities already part of a municipality, it may be 199 reasonable to set revalidation periods of 6 months or longer, 200 especially if the URI mechanism is widely deployed at both the server 201 and the clients. In areas that are quickly growing, 20-30 day 202 revalidation may be more appropriate even though such revalidation 203 would be the majority of the traffic on the LoST server. 205 When a planned change is made, typically the TTL for the affected 206 records is lowered, so that revalidation is forced soon after the 207 change is implemented. It is not advisable to set the expiration 208 precisely at the planned change time if a large number of records 209 will be changed, since that would cause a large spike in traffic at 210 the change time. Rather, the expiration time should have a random 211 additional time added to it to spread out the load. 213 6. Relax NG Schema 215 The Relax NG schema in [RFC5222] is extended to include: 217 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 218 default namespace ns1 = "urn:ietf:params:xml:ns:lost-plannedChange1" 220 ## 221 ## Extension to Location-to-Service Translation (LoST) Protocol 222 ## to support a planned change to location data 223 ## 224 ## plannedChange is used in the extensionPoint of 225 ## commonRequestPattern in a findService request 226 ## 227 ## locationInvalidated is used by the LoST server to notify a 228 ## LIS that a previously valid location may be (or will become) 229 ## invalid 230 ## 231 ## ttl is used in the extensionPoint of 232 ## commonResponsePattern in a findService response 233 ## 234 ## uriNotStored is a new warning to be used in a 235 ## exceptionContainer in the warnings element of a 236 ## findServiceResponse 237 ## 238 start = 239 plannedChange 240 | locationInvalidated 241 | uriNotStored 242 ## 243 ## plannedChange 244 ## 245 div { 246 plannedChange = 247 element plannedChange { 248 attribute uri { 249 xsd:anyURI }?, 250 attribute asOf { 251 xsd:dateTime }?, 252 extensionPoint+ 253 } 254 } 256 ## 257 ## locationInvalidated 258 ## 259 div { 260 locationInvalidated = 261 element locationInvalidated { 262 attribute asOf { 263 xsd:dateTime }?, 264 extensionPoint+ 265 } 266 } 268 ## 269 ## ttl 270 ## 271 div { 272 ttl = 273 element ttl { 274 expires, 275 extensionPoint+ 276 } 277 } 279 ## 280 ## uriNotStored 281 ## 282 div { 283 uriNotStored = 284 element uriNotStored { basicException } 286 } 288 ## 289 ## Patterns for inclusion of elements from schemas in 290 ## other namespaces. 291 ## 292 div { 294 ## 295 ## Any element not in the LoST namespace. 296 ## 297 notLostChange = element * - (ns1:* | ns1:*) { anyElement } 299 ## 300 ## A wildcard pattern for including any element 301 ## from any other namespace. 302 ## 303 anyElement = 304 (element * { anyElement } 305 | attribute * { text } 306 | text)* 308 ## 309 ## A point where future extensions 310 ## (elements from other namespaces) 311 ## can be added. 312 ## 313 extensionPoint = notLostChanged* 314 } 316 7. Security Considerations 318 As an extension to LoST, this document inherits the security issues 319 raised in [RFC5222]. The server could be tricked into storing a 320 malicious URI which, when sent the locationInvalidated object could 321 trigger something untoward. The server MUST NOT accept any data from 322 the client in response to POSTing the locationInvalidated. 324 The server is subject to abuse by clients because it is being asked 325 to store something and may need to send data to an uncontrolled URI. 326 Clients could request many URIs for the same location for example. 327 The server MUST have policy that limits use of this mechanism by a 328 given client. If the policy is exceeded, the server returns the 329 uriNotStored warning. The server MUST validate that the content of 330 the uri sent is syntactically valid and meets the 256 byte limit. 331 When sending the locationInvalidated object to the uri stored, the 332 server MUST protect itself against common http vulnerabilities. 334 The mutual authentication between client and server when is 335 RECOMMENDED for both the initial findService operation that requests 336 storing the uri and the sending of the locationInvalidated object. 337 The server should be well known to the client, and its credential 338 should be learned in a reliable way. For example, a public safety 339 system operating the LoST server may have a credential traceable to a 340 well known Certificate Authority known to provide credentials for 341 public safety agencies. Many of the clients will be operated by 342 local ISPs or other service providers where the server operator can 343 reasonably obtain a good credential to use for the URI. Where the 344 server does not recognize the client, its policy MAY limit the use of 345 this feature beyond what it would limit a client it recognized. 347 8. IANA Considerations 349 8.1. Relax NG Schema Registration 351 URI: urn:ietf:params:xml:schema:lost-planedChange1 353 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 354 (br@brianrosen.net). 356 Relax NG Schema: The Relax NG schema to be registered is contained 357 in Section 5. Its first line is 359 default namespace = "urn:ietf:params:xml:ns:lost-PlannedChange1 361 and its last line is 363 } 365 8.2. LoST Namespace Registration 366 URI: urn:ietf:params:xml:ns:lost-plannedChange1 368 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 369 (br@brianrosen.net). 371 XML: 373 BEGIN 374 375 377 378 379 381 LoST Planned Change Namespace 382 383 384

Namespace for LoST Planned Change extension

385

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

386

See 387 RFC????.

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