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

Namespace for LoST Planned Change extension

403

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

404

See 405 RFC????.

406 407 408 END 410 10. Normative References 412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 413 Requirement Levels", BCP 14, RFC 2119, 414 DOI 10.17487/RFC2119, March 1997, 415 . 417 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 418 Tschofenig, "LoST: A Location-to-Service Translation 419 Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, 420 . 422 Author's Address 424 Brian Rosen 425 Neustar 426 470 Conrad Dr 427 Mars, PA 16046 428 US 430 EMail: br@brianrosen.net