idnits 2.17.1 draft-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: ---------------------------------------------------------------------------- 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 18, 2016) is 2839 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 18, 2016 5 Expires: January 19, 2017 7 Validation of Locations Around a Planned Change 8 draft-ecrit-lost-planned-changes-00 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 TTL element to the response, which informs all queriers the 21 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 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 19, 2017. 40 Copyright Notice 42 Copyright (c) 2016 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. uri Not Stored Warning . . . . . . . . . . . . . . . . . . . 4 62 6. 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 . . . . . . . . . . . . . . . . . . . . 9 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 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 lt;findserviceResponse> is also extended to 82 provide a 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 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 effectivity date and time (typically 00:00 92 on 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 LI 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 LI 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 "asOf" 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 lt;findserviceResponse> 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 less than 256 bytes. Each client of the server 153 may only store one URI against a location, where "location" is 154 defined by policy at the server, since a given unique location may 155 have many combinations of LI elements that resolve to the same 156 location. If the server receives a 'uri' for the same location from 157 the same client, the URI in the request replaces the URI it 158 previously retained. Policy at the server may limit how many uris it 159 retains for a given location. A new warning is defined below to be 160 used to indicate that the URI has not been stored. If the location 161 in the request is invalid, the uri will not be stored and the warning 162 will 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 plannedChange 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 plannedChange 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. TTL in Response 197 A new 'ttl' element is added to the lt;findserviceResponse>. The ttl 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' pattern, which allows explicit 'No 202 Cache' and 'No Expiration' values to be returned. 'No Cache' has no 203 meaning and MUST NOT be returned in TTL. 'No Expiration' means the 204 server does not have any suggested revalidation period. 206 Selecting a revalidation interval is a complex balancing of 207 timeliness, server load, stability of the underlying data, and policy 208 of the LoST server. Too short, and load on the server may overwhelm 209 it. Too long and invalid data may persist in the server for too 210 long. The URI mechanism provides timely notice to coordinate 211 changes, but even with it, it is often advisable to revalidate data 212 eventually. 214 In areas that have little change in data, such as fully built out, 215 stable communities already part of a municipality, it may be 216 reasonable to set revalidation periods of 6 months or longer, 217 especially if the URI mechanism is widely deployed at both the server 218 and the clients. In areas that are quickly growing, 20-30 day 219 revalidation may be more appropriate even though such revalidation 220 would be the majority of the traffic on the LoST server. 222 When a planned change is made, typically the TTL for the affected 223 records is lowered, so that revalidation is forced soon after the 224 change is implemented. It is not advisable to set the expiration 225 precisely at the planned change time if a large number of records 226 will be changed, since that would cause a large spike in traffic at 227 the change time. Rather, the expiration time should have a random 228 additional time added to it to spread out the load. 230 7. Relax NG Schema 232 The Relax NG schema in [RFC5222] is extended to include: 234 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 235 default namespace ns1 = "urn:ietf:params:xml:ns:lost-plannedChange1" 237 ## 238 ## Extension to Location-to-Service Translation (LoST) Protocol 239 ## to support a planned change to location data 240 ## 241 ## plannedChange is used in the extensionPoint of 242 ## commonRequestPattern in a findService request 243 ## 244 ## locationInvalidated is used by the LoST server to notify a 245 ## LIS that a previously valid location may be (or will become) 246 ## invalid 247 ## 248 ## ttl is used in the extensionPoint of 249 ## commonResponsePattern in a findService response 250 ## 251 ## uriNotStored is a new warning to be used in a 252 ## exceptionContainer in the warnings element of a 253 ## findServiceResponse 254 ## 255 start = 256 plannedChange 257 | locationInvalidated 258 | uriNotStored 259 ## 260 ## plannedChange 261 ## 262 div { 263 plannedChange = 264 element plannedChange { 265 attribute uri { 266 xsd:anyURI }?, 267 attribute asOf { 268 xsd:dateTime }?, 269 extensionPoint+ 270 } 271 } 273 ## 274 ## locationInvalidated 275 ## 276 div { 277 locationInvalidated = 278 element locationInvalidated { 279 attribute asOf { 280 xsd:dateTime }?, 281 extensionPoint+ 282 } 283 } 285 ## 286 ## ttl 287 ## 288 div { 289 ttl = 290 element ttl { 291 expires, 292 extensionPoint+ 293 } 294 } 296 ## 297 ## uriNotStored 298 ## 299 div { 300 uriNotStored = 301 element uriNotStored { basicException } 302 } 304 ## 305 ## Patterns for inclusion of elements from schemas in 306 ## other namespaces. 307 ## 308 div { 310 ## 311 ## Any element not in the LoST namespace. 312 ## 313 notLostChange = element * - (ns1:* | ns1:*) { anyElement } 315 ## 316 ## A wildcard pattern for including any element 317 ## from any other namespace. 318 ## 319 anyElement = 320 (element * { anyElement } 321 | attribute * { text } 322 | text)* 324 ## 325 ## A point where future extensions 326 ## (elements from other namespaces) 327 ## can be added. 328 ## 329 extensionPoint = notLostChanged* 330 } 332 8. Security Considerations 334 As an extension to LoST, this document inherits the security issues 335 raised in [RFC5222]. The server could be tricked into storing a 336 malicious URI which, when sent the locationInvalidated object could 337 trigger something untoward. The server MUST NOT accept any data from 338 the client in response to POSTing the locationInvalidated. 340 The server is subject to abuse by clients because it is being asked 341 to store something and may need to send data to an uncontrolled URI. 342 Clients could request many URIs for the same location for example. 343 The server MUST have policy that limits use of this mechanism by a 344 given client. If the policy is exceeded, the server returns the 345 uriNotStored warning. The server MUST validate that the content of 346 the uri sent is syntactically valid and meets the 256 byte limit. 347 When sending the locationInvalidated object to the uri stored, the 348 server MUST protect itself against common http vulnerabilities. 350 The mutual authentication between client and server when is 351 RECOMMENDED for both the initial findService operation that requests 352 storing the uri and the sending of the locationInvalidated object. 353 The server should be well known to the client, and its credential 354 should be learned in a reliable way. For example, a public safety 355 system operating the LoST server may have a credential traceable to a 356 well known Certificate Authority known to provide credentials for 357 public safety agencies. Many of the clients will be operated by 358 local ISPs or other service providers where the server operator can 359 reasonably obtain a good credential to use for the URI. Where the 360 server does not recognize the client, its policy MAY limit the use of 361 this feature beyond what it would limit a client it recognized. 363 9. IANA Considerations 365 9.1. Relax NG Schema Registration 367 URI: urn:ietf:params:xml:schema:lost-planedChange1 369 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 370 (br@brianrosen.net). 372 Relax NG Schema: The Relax NG schema to be registered is contained 373 in Section 5. Its first line is 375 default namespace = "urn:ietf:params:xml:ns:lost-PlannedChange1 377 and its last line is 379 } 381 9.2. LoST Namespace Registration 383 URI: urn:ietf:params:xml:ns:lost-plannedChange1 385 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 386 (br@brianrosen.net). 388 XML: 390 BEGIN 391 392 394 395 396 398 LoST Planned Change Namespace 399 400 401

Namespace for LoST Planned Change extension

402

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

403

See 404 RFC????.

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