idnits 2.17.1 draft-ietf-cdni-control-triggers-07.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 (June 30, 2015) is 3221 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) == Missing Reference: 'RFCthis' is mentioned on line 1819, but not defined ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-05 == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-09 == Outdated reference: A later version (-20) exists of draft-ietf-cdni-redirection-09 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Murray 3 Internet-Draft B. Niven-Jenkins 4 Intended status: Standards Track Velocix (Alcatel-Lucent) 5 Expires: January 1, 2016 June 30, 2015 7 CDNI Control Interface / Triggers 8 draft-ietf-cdni-control-triggers-07 10 Abstract 12 This document describes the part of the CDN Interconnection Control 13 Interface that allows a CDN to trigger activity in an interconnected 14 CDN that is configured to deliver content on its behalf. The 15 upstream CDN can use this mechanism to request that the downstream 16 CDN pre-positions metadata or content, or that it invalidates or 17 purges metadata or content. The upstream CDN can monitor the status 18 of activity that it has triggered in the downstream CDN. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 1, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Model for CDNI Triggers . . . . . . . . . . . . . . . . . . . 4 63 2.1. Timing of Triggered Activity . . . . . . . . . . . . . . 6 64 2.2. Scope of Triggered Activity . . . . . . . . . . . . . . . 6 65 2.3. Trigger Results . . . . . . . . . . . . . . . . . . . . . 7 66 3. Collections of Trigger Status Resources . . . . . . . . . . . 7 67 4. CDNI Trigger Interface . . . . . . . . . . . . . . . . . . . 8 68 4.1. Creating Triggers . . . . . . . . . . . . . . . . . . . . 9 69 4.2. Checking Status . . . . . . . . . . . . . . . . . . . . . 10 70 4.2.1. Polling Trigger Status Resource collections . . . . . 10 71 4.2.2. Polling Trigger Status Resources . . . . . . . . . . 11 72 4.3. Cancelling Triggers . . . . . . . . . . . . . . . . . . . 11 73 4.4. Deleting Triggers . . . . . . . . . . . . . . . . . . . . 12 74 4.5. Expiry of Trigger Status Resources . . . . . . . . . . . 12 75 4.6. Loop Detection and Prevention . . . . . . . . . . . . . . 13 76 4.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 13 77 4.8. Content URLs . . . . . . . . . . . . . . . . . . . . . . 14 78 5. CI/T Object Properties and Encoding . . . . . . . . . . . . . 15 79 5.1. CI/T Objects . . . . . . . . . . . . . . . . . . . . . . 15 80 5.1.1. CI/T Commands . . . . . . . . . . . . . . . . . . . . 15 81 5.1.2. Trigger Status Resource . . . . . . . . . . . . . . . 16 82 5.1.3. Trigger Collection . . . . . . . . . . . . . . . . . 17 83 5.2. Properties of CI/T Objects . . . . . . . . . . . . . . . 19 84 5.2.1. Trigger Specification . . . . . . . . . . . . . . . . 19 85 5.2.2. Trigger Type . . . . . . . . . . . . . . . . . . . . 20 86 5.2.3. Trigger Status . . . . . . . . . . . . . . . . . . . 21 87 5.2.4. PatternMatch . . . . . . . . . . . . . . . . . . . . 21 88 5.2.5. Absolute Time . . . . . . . . . . . . . . . . . . . . 22 89 5.2.6. Error Description . . . . . . . . . . . . . . . . . . 22 90 5.2.7. Error Code . . . . . . . . . . . . . . . . . . . . . 23 91 5.3. Formalization of the JSON Data . . . . . . . . . . . . . 24 92 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 6.1. Creating Triggers . . . . . . . . . . . . . . . . . . . . 26 94 6.1.1. Preposition . . . . . . . . . . . . . . . . . . . . . 26 95 6.1.2. Invalidate . . . . . . . . . . . . . . . . . . . . . 27 97 6.2. Examining Trigger Status . . . . . . . . . . . . . . . . 29 98 6.2.1. Collection of All Triggers . . . . . . . . . . . . . 29 99 6.2.2. Filtered Collections of Trigger Status Resources . . 30 100 6.2.3. Individual Trigger Status Resources . . . . . . . . . 31 101 6.2.4. Polling for Change . . . . . . . . . . . . . . . . . 33 102 6.2.5. Deleting Trigger Status Resources . . . . . . . . . . 36 103 6.2.6. Error Reporting . . . . . . . . . . . . . . . . . . . 38 104 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 105 7.1. Media type registrations . . . . . . . . . . . . . . . . 39 106 7.1.1. CI/T Commands . . . . . . . . . . . . . . . . . . . . 39 107 7.1.2. CI/T Trigger Status Resource . . . . . . . . . . . . 40 108 7.1.3. CI/T Trigger Collection . . . . . . . . . . . . . . . 41 109 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 110 8.1. Authentication, Authorization, Confidentiality, Integrity 111 Protection . . . . . . . . . . . . . . . . . . . . . . . 42 112 8.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 43 113 8.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 43 114 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 115 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 116 10.1. Normative References . . . . . . . . . . . . . . . . . . 44 117 10.2. Informative References . . . . . . . . . . . . . . . . . 44 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 120 1. Introduction 122 [RFC6707] introduces the problem scope for CDN Interconnection (CDNI) 123 and lists the four categories of interfaces that may be used to 124 compose a CDNI solution (Control, Metadata, Request Routing, 125 Logging). 127 [RFC7336] expands on the information provided in [RFC6707] and 128 describes each of the interfaces and the relationships between them 129 in more detail. 131 This document describes the "CI/T" interface, "CDNI Control interface 132 / Triggers". It does not consider those parts of the control 133 interface that relate to configuration, bootstrapping or 134 authentication of CDN Interconnect interfaces. Section 4 of 135 [RFC7337] identifies the requirements specific to the CI interface, 136 requirements applicable to the CI/T interface are CI-1 to CI-6. 138 o Section 2 outlines the model for the CI/T Interface at a high 139 level. 141 o Section 3 describes collections of Trigger Status Resources. 143 o Section 4 defines the web service provided by the dCDN. 145 o Section 5 lists properties of CI/T Commands and Status Resources. 147 o Section 6 contains example messages. 149 1.1. Terminology 151 This document reuses the terminology defined in [RFC6707]. 153 2. Model for CDNI Triggers 155 A CI/T Command, sent from the uCDN to the dCDN, is a request for the 156 dCDN to do some work relating to data associated with content 157 requests originating from the uCDN. 159 There are two types of CI/T Command, CI/T Trigger Commands and CI/T 160 Cancel Commands. The CI/T Cancel Command can be used to request 161 cancellation of an earlier CI/T Trigger Command. A CI/T Trigger 162 Command is of one of the following types: 164 o preposition - used to instruct the dCDN to fetch metadata from the 165 uCDN, or content from any origin including the uCDN. 167 o invalidate - used to instruct the dCDN to revalidate specific 168 metadata or content before re-using it. 170 o purge - used to instruct the dCDN to delete specific metadata or 171 content. 173 The CI/T interface is a web service offered by the dCDN. It allows 174 CI/T commands to be issued, and triggered activity to be tracked. 175 When the dCDN accepts a CI/T Command it creates a resource describing 176 status of the triggered activity, a Trigger Status Resource. The 177 uCDN can poll Trigger Status Resources to monitor progress. 179 The dCDN maintains at least one collection of Trigger Status 180 Resources for each uCDN. Each uCDN only has access to its own 181 collections, the locations of which are shared when CDN 182 interconnection is established. 184 To trigger activity in the dCDN, the uCDN POSTs a CI/T Command to the 185 collection of Trigger Status Resources. If the dCDN accepts the CI/T 186 Command, it creates a new Trigger Status Resource and returns its 187 location to the uCDN. To monitor progress, the uCDN can GET the 188 Trigger Status Resource. To request cancellation of a CI/T Trigger 189 Command the uCDN can POST to the collection of Trigger Status 190 Resources, or simply DELETE the Trigger Status Resource. 192 In addition to the collection of all Trigger Status Resources for the 193 uCDN, the dCDN can maintain filtered views of that collection. These 194 filtered views are defined in Section 3 and include collections of 195 Trigger Status Resources corresponding to active and completed CI/T 196 Trigger Commands. These collections provide a mechanism for polling 197 the status of multiple jobs. 199 Figure 1 is an example showing the basic message flow used by the 200 uCDN to trigger activity in the dCDN, and for the uCDN to discover 201 the status of that activity. Only successful triggering is shown. 202 Examples of the messages are given in Section 6. 204 uCDN dCDN 205 | (1) POST http://dcdn.example.com/triggers/uCDN | 206 [ ] --------------------------------------------------> [ ]--+ 207 | [ ] | (2) 208 | (3) HTTP 201 Response [ ]<-+ 209 [ ] <-------------------------------------------------- [ ] 210 | Loc: http://dcdn.example.com/triggers/uCDN/123 | 211 | | 212 . . . 213 . . . 214 . . . 215 | | 216 | (4) GET http://dcdn.example.com/triggers/uCDN/123 | 217 [ ] --------------------------------------------------> [ ] 218 | [ ] 219 | (5) HTTP 200 Trigger Status Resource [ ] 220 [ ] <-------------------------------------------------- [ ] 221 | | 222 | | 224 Figure 1: Basic CDNI Message Flow for Triggers 226 The steps in Figure 1 are: 228 1. The uCDN triggers action in the dCDN by posting a CI/T Command to 229 a collection of Trigger Status Resources, 230 "http://dcdn.example.com/triggers/uCDN". The URL of this was 231 given to the uCDN when the CI/T interface was established. 233 2. The dCDN authenticates the request, validates the CI/T Command 234 and, if it accepts the request, creates a new Trigger Status 235 Resource. 237 3. The dCDN responds to the uCDN with an HTTP 201 response status, 238 and the location of the Trigger Status Resource. 240 4. The uCDN can poll, possibly repeatedly, the Trigger Status 241 Resource in the dCDN. 243 5. The dCDN responds with the Trigger Status Resource, describing 244 progress or results of the CI/T Trigger Command. 246 The remainder of this document describes the messages, Trigger Status 247 Resources, and collections of Trigger Status Resources in more 248 detail. 250 2.1. Timing of Triggered Activity 252 Timing of the execution of CI/T Commands is under the dCDN's control, 253 including its start-time and pacing of the activity in the network. 255 CI/T invalidate and purge commands MUST be applied to all data 256 acquired before the command was accepted by the dCDN. The dCDN 257 SHOULD NOT apply CI/T invalidate and purge commands to data acquired 258 after the CI/T Command was accepted, but this may not always be 259 achievable so the uCDN cannot count on that. 261 If the uCDN wishes to invalidate or purge content then immediately 262 pre-position replacement content at the same URLs, it SHOULD ensure 263 the dCDN has completed the invalidate/purge before initiating the 264 prepositioning. Otherwise, there is a risk that the dCDN pre- 265 positions the new content, then immediately invalidates or purges it 266 (as a result of the two uCDN requests running in parallel). 268 Because the CI/T Command timing is under the dCDN's control, the dCDN 269 implementation can choose whether to apply CI/T invalidate and purge 270 commands to content acquisition that has already started when the 271 command is received. 273 2.2. Scope of Triggered Activity 275 Each CI/T Command can operate on multiple metadata and content URLs. 277 Multiple representations of an HTTP resource may share the same URL. 278 CI/T Trigger Commands that invalidate or purge metadata or content 279 apply to all resource representations with matching URLs. 281 The dCDN MUST reject CI/T Commands from a uCDN that act on another 282 uCDN's data. Security considerations are discussed further in 283 section Section 8. 285 2.3. Trigger Results 287 Possible states for a Trigger Status Resource are defined in section 288 Section 5.2.3. 290 The CI/T Trigger Command MUST NOT be reported as 'complete' until all 291 actions have been completed successfully. The reasons for failure, 292 and URLs or Patterns affected, SHOULD be enumerated in the Trigger 293 Status Resource. For more detail, see section Section 4.7. 295 If a dCDN is also acting as a uCDN in a cascade, it MUST forward CI/T 296 Commands to any downstream CDNs that may be affected. The CI/T 297 Trigger Command MUST NOT be reported as 'complete' in a CDN until it 298 is 'complete' in all of its downstream CDNs. If a CI/T Trigger 299 Command is reported as 'processed' in any dCDN, intermediate CDNs 300 MUST NOT report 'complete', instead they must also report 301 'processed'. A CI/T Command MAY be reported as 'failed' as soon as 302 it fails in a CDN or in any of its downstream CDNs. A cancelled CI/T 303 Trigger Command MUST be reported as 'cancelling' until it has been 304 reported as 'cancelled', 'complete', or 'failed' by all dCDNs in a 305 cascade. 307 3. Collections of Trigger Status Resources 309 As described in Section 2, Trigger Status Resources exist in the dCDN 310 to report the status of activity triggered by each uCDN. 312 A collection of Trigger Status Resources is a resource that contains 313 a reference to each Trigger Status Resource in that collection. 315 The dCDN MUST make a collection of a uCDN's Trigger Status Resources 316 available to that uCDN. This collection includes all of the Trigger 317 Status Resources created for CI/T Commands from the uCDN that have 318 been accepted by the dCDN, and have not yet been deleted by the uCDN, 319 or expired and removed by the dCDN (as described in section 320 Section 4.4). Trigger Status Resources belonging to a uCDN MUST NOT 321 be visible to any other CDN. The dCDN could, for example, achieve 322 this by offering different collection URLs to each uCDN, and/or by 323 filtering the response based on the uCDN with which the HTTP client 324 is associated. 326 To trigger activity in a dCDN, or to cancel triggered activity, the 327 uCDN POSTs a CI/T Command to the dCDN's collection of the uCDN's 328 Trigger Status Resources. 330 In order to allow the uCDN to check the status of multiple jobs in a 331 single request, the dCDN SHOULD also maintain collections 332 representing filtered views of the collection of all Trigger Status 333 Resources. These filtered collections are optional-to-implement but, 334 if implemented, the dCDN MUST include links to them in the collection 335 of all Trigger Status Resources. The filtered collections are: 337 o Pending - Trigger Status Resources for CI/T Trigger Commands that 338 have been accepted, but not yet acted upon. 340 o Active - Trigger Status Resources for CI/T Trigger Commands that 341 are currently being processed in the dCDN. 343 o Complete - Trigger Status Resources representing activity that 344 completed successfully, and 'processed' CI/T Trigger Commands for 345 which no further status updates will be made by the dCDN. 347 o Failed - Trigger Status Resources representing CI/T Commands that 348 failes or were cancelled by the uCDN. 350 4. CDNI Trigger Interface 352 This section describes an interface to enable an upstream CDN to 353 trigger activity in a downstream CDN. 355 The CI/T interface builds on top of HTTP, so dCDNs may make use of 356 any HTTP feature when implementing the CI/T interface. For example, 357 a dCDN SHOULD make use of HTTP's caching mechanisms to indicate that 358 a requested response/representation has not been modified, reducing 359 the uCDN's processing needed to determine whether the status of 360 triggered activity has changed. 362 All dCDNs implementing CI/T MUST support the HTTP GET, HEAD, POST and 363 DELETE methods as defined in [RFC7231]. 365 The only representation specified in this document is JSON, 366 [RFC7159]. It MUST be supported by the uCDN and by the dCDN. 368 The URL of the dCDN's collection of all Trigger Status Resources 369 needs to be either discovered by, or configured in, the uCDN. The 370 mechanism for discovery of that URL is outside the scope of this 371 document. 373 CI/T Commands are POSTed to the dCDN's collection of all Trigger 374 Status Resources. If a CI/T Trigger Command is accepted by the dCDN, 375 the dCDN creates a new Trigger Status Resource and returns its URI to 376 the uCDN in an HTTP 201 response. The triggered activity can then be 377 monitored by the uCDN using that resource and the collections 378 described in Section 3. 380 The URI of each Trigger Status Resource is returned to the uCDN when 381 it is created, and URIs of all Trigger Status Resources are listed in 382 the dCDN's collection of all Trigger Status Resources. This means 383 all Trigger Status Resources can be discovered by the uCDN, so dCDNs 384 are free to assign whatever structure they desire to the URIs for CI/ 385 T resources. Therefore uCDNs MUST NOT make any assumptions regarding 386 the structure of CI/T URIs or the mapping between CI/T objects and 387 their associated URIs. URIs present in the examples in this document 388 are purely illustrative and are not intended to impose a definitive 389 structure on CI/T interface implementations. 391 4.1. Creating Triggers 393 To issue a CI/T Command, the uCDN makes an HTTP POST to the dCDN's 394 collection of all of the uCDN's Trigger Status Resources. The 395 request body of that POST is a CI/T Command, as described in 396 Section 5.1.1. 398 The dCDN validates the CI/T Command, if it is malformed or the uCDN 399 does not have sufficient access rights it MUST either respond with an 400 appropriate 4xx HTTP error code and a Trigger Status Resource MUST 401 NOT be created on the dCDN, or create a 'failed' Trigger Status 402 Resource containing an appropriate error description. 404 When a CI/T Trigger Command is accepted, the uCDN MUST create a new 405 Trigger Status Resource which will convey a specification of the CI/T 406 Command and its current status. The HTTP response to the dCDN MUST 407 have status code 201 and MUST convey the URI of the Trigger Status 408 Resource in the Location header field. The HTTP response SHOULD 409 include the content of the newly created Trigger Status Resource, 410 this is recommended particularly in cases where the CI/T Trigger 411 Command has completed immediately. 413 Once a Trigger Status Resource has been created the dCDN MUST NOT re- 414 use its URI, even after that Trigger Status Resource has been 415 removed. 417 The dCDN SHOULD track and report on progress of CI/T Trigger 418 Commands. If the dCDN is not able to do that, it MUST indicate that 419 it has accepted the request but will not be providing further status 420 updates. To do this, it sets the "status" of the Trigger Status 421 Resource to "processed". In this case, CI/T processing should 422 continue as for a "complete" request, so the Trigger Status Resource 423 MUST be added to the dCDN's collection of Complete Trigger Status 424 Resources. The dCDN SHOULD also provide an estimated completion time 425 for the request, by using the "etime" property of the Trigger Status 426 Resource. This will allow the uCDN to schedule prepositioning after 427 an earlier delete of the same URLs is expected to have finished. 429 If the dCDN is able to track the execution of CI/T Commands and a CI/ 430 T Command is queued by the dCDN for later action, the "status" 431 property of the Trigger Status Resource MUST be "pending". Once 432 processing has started the "status" MUST be "active". Finally, once 433 the CI/T Command is complete, the status MUST be set to "complete" or 434 "failed". 436 A CI/T Trigger Command may result in no activity in the dCDN if, for 437 example, it is an invalidate or purge request for data the dCDN has 438 not yet acquired, or a prepopulate request for data it has already 439 acquired and which is still valid. In this case, the "status" of the 440 Trigger Status Resource MUST be "processed" or "complete", and the 441 Trigger Status Resource MUST be added to the dCDN's collection of 442 Complete Trigger Status Resources. 444 Once created, Trigger Status Resources can be cancelled or deleted by 445 the uCDN, but not modified. The dCDN MUST reject PUT and POST 446 requests from the uCDN to Trigger Status Resources by responding with 447 an appropriate HTTP status code, for example 405 "Method Not 448 Allowed". 450 4.2. Checking Status 452 The uCDN has two ways to check progress of CI/T Commands it has 453 issued to the dCDN, described in sections Section 4.2.1 and 454 Section 4.2.2. 456 To check for change in status of a Trigger Status Resource or 457 collection of Trigger Status Resources without re-fetching the whole 458 Resource or Collection, Entity Tags SHOULD be included by the dCDN 459 for the uCDN to use as cache validators, as defined in [RFC7232]. 461 The dCDN SHOULD use the cache control headers for responses to GETs 462 for Trigger Status Resources and Collections to indicate the 463 frequency at which it recommends the uCDN should poll for change. 465 4.2.1. Polling Trigger Status Resource collections 467 The uCDN can fetch the collection of its Trigger Status Resources, or 468 filtered views of that collection. 470 This makes it possible to poll status of all CI/T Trigger Commands in 471 a single request. If the dCDN moves a Trigger Status Resource from 472 the Active to the Completed collection, the uCDN can fetch the result 473 of that activity. 475 When polling in this way, the uCDN SHOULD use HTTP Entity Tags to 476 monitor for change, rather than repeatedly fetching the whole 477 collection. An example of this is given in section Section 6.2.4. 479 4.2.2. Polling Trigger Status Resources 481 The uCDN has a URI provided by the dCDN for each Trigger Status 482 Resource it has created, it may fetch that Trigger Status Resource at 483 any time. 485 This can be used to retrieve progress information, and to fetch the 486 result of the CI/T Command. 488 When polling in this way, the uCDN SHOULD use HTTP Entity Tags to 489 monitor for change, rather than repeatedly fetching the Trigger 490 Status Resource. 492 4.3. Cancelling Triggers 494 The uCDN can request cancellation of a CI/T Trigger Command by 495 POSTing a CI/T Cancel Command to the collection of all Trigger Status 496 Resources. 498 Cancellation of a CI/T Trigger Command is optional-to-implement in 499 the dCDN. 501 The dCDN MUST respond to the CI/T Cancel Command appropriately, for 502 example with HTTP status code 200 "OK" if the cancellation has been 503 processed and the CI/T Command is inactive, 202 "Accepted" if the 504 command has been accepted but the CI/T Command remains active, or 501 505 "Not Implemented" if cancellation is not supported by the dCDN. 507 If cancellation of a "pending" Trigger Status Resource is accepted by 508 the dCDN, the dCDN SHOULD NOT start processing of that activity. 509 Issuing a CT/T cancel command for a "pending" Trigger Status Resource 510 does not however guarantee that the corresponding activity will not 511 be started, because the uCDN cannot control the timing of that 512 activity. Processing could, for example, start after the POST is 513 sent by the uCDN but before that request is processed by the dCDN. 515 If cancellation of an "active" or "processed" Trigger Status Resource 516 is accepted by the dCDN, the dCDN SHOULD stop processing the CI/T 517 Command. However, as with cancellation of a "pending" CI/T Command, 518 the dCDN does not guarantee this. 520 If the CI/T Command cannot be stopped immediately, the status in the 521 corresponding Trigger Status Resource MUST be set to "cancelling", 522 and the Trigger Status Resource MUST remain in the collection of 523 Trigger Status Resources for active CI/T Commands. If processing is 524 stopped before normal completion, the status value in the Trigger 525 Status Resource MUST be set to "cancelled", and the Trigger Status 526 Resource MUST be included in the collection of failed CT/T Trigger 527 Commands. 529 Cancellation of a "complete" or "failed" Trigger Status Resource 530 requires no processing in the dCDN, its status MUST NOT be changed to 531 "cancelled". 533 4.4. Deleting Triggers 535 The uCDN can delete Trigger Status Resources at any time, using the 536 HTTP DELETE method. The effect is similar to cancellation, but no 537 Trigger Status Resource remains afterwards. 539 Once deleted, the references to a Trigger Status Resource MUST be 540 removed from all Trigger Status Resource collections. Subsequent 541 requests to GET the deleted Trigger Status Resource SHOULD be 542 rejected by the dCDN with an HTTP error. 544 If a "pending" Trigger Status Resource is deleted, the dCDN SHOULD 545 NOT start processing of that activity. Deleting a "pending" Trigger 546 Status Resource does not however guarantee that it has not started 547 because the uCDN cannot control the timing of that activity. 548 Processing may, for example, start after the DELETE is sent by the 549 uCDN but before that request is processed by the dCDN. 551 If an "active" or "processed" Trigger Status Resource is deleted, the 552 dCDN SHOULD stop processing the CI/T Command. However, as with 553 deletion of a "pending" Trigger Status Resource, the dCDN does not 554 guarantee this. 556 Deletion of a "complete" or "failed" Trigger Status Resource requires 557 no processing in the dCDN other than deletion of the Trigger Status 558 Resource. 560 4.5. Expiry of Trigger Status Resources 562 The dCDN can choose to automatically delete Trigger Status Resources 563 some time after they become "complete", "processed", "failed" or 564 "cancelled". In this case, the dCDN will remove the Trigger Status 565 Resource and respond to subsequent requests for it with an HTTP 566 error. 568 If the dCDN performs this housekeeping, it MUST have reported the 569 length of time after which completed Trigger Status Resources will be 570 deleted via a property of the collection of all Trigger Status 571 Resources. It is RECOMMENDED that Trigger Status Resources are not 572 automatically deleted by the dCDN for at least 24 hours after they 573 become "complete", "processed", "failed" or "cancelled". 575 To ensure it is able to get the status of its Trigger Status 576 Resources for completed and failed CI/T Commands, it is RECOMMENDED 577 that the uCDN polling interval is less than the time after which 578 records for completed activity will be deleted. 580 4.6. Loop Detection and Prevention 582 Given three CDNs, A, B and C. If CDNs B and C delegate delivery of 583 CDN A's content to each other, CDN A's CI/T Commands could be passed 584 between CDNs B and C in a loop. More complex networks of CDNs could 585 contain similar loops involving more hops. 587 In order to prevent and detect such CI/T loops, each CDN uses a CDN 588 Provider ID to uniquely identify itself. In every CI/T Command it 589 originates or cascades, each CDN MUST append an array element 590 containing its CDN Provider ID to a JSON array under an entry named 591 "cdn-path". When receiving CI/T Commands a dCDN MUST check the cdn- 592 path and reject any CI/T Command which already contains its own CDN 593 Provider ID in the cdn-path. Transit CDNs MUST check the cdn-path 594 and not cascade the CI/T Command to dCDNs that are already listed in 595 cdn-path. 597 The CDN Provider Id consists of the two characters "AS" followed by 598 the CDN Provider's Autonomous System number, then a colon (':') and 599 an additional qualifier that is used to guarantee uniqueness in case 600 a particular AS has multiple independent CDNs deployed. For example 601 "AS64496:0". 603 If the CDN provider has multiple Autonomous Systems, the same AS 604 number SHOULD be used in all messages from that CDN provider, unless 605 there are multiple distinct CDNs. 607 If the RI interface described in [I-D.ietf-cdni-redirection] is 608 implemented by the dCDN, the CI/T and RI interfaces SHOULD use the 609 same CDN Provider Id. 611 4.7. Error Handling 613 A dCDN can signal rejection of a CI/T Command using HTTP status 614 codes. For example, 400 if the request is malformed, or 403 or 404 615 if the uCDN does not have permission to issue CI/T Commands or it is 616 trying to act on another CDN's data. 618 If any part of the CI/T Trigger Command fails, the trigger SHOULD be 619 reported as "failed" once its activity is complete or if no further 620 errors will be reported. The "errors" property in the Trigger Status 621 Resource will be used to enumerate which actions failed and the 622 reasons for failure, and can be present while the Trigger Status 623 Resource is still "pending" or "active", if the CI/T Trigger Command 624 is still running for some URLs or Patterns in the Trigger 625 Specification. 627 Once a request has been accepted, processing errors are reported in 628 the Trigger Status Resource using a list of Error Descriptions. Each 629 Error Description is used to report errors against one or more of the 630 URLs or Patterns in the Trigger Specification. 632 If a surrogate affected by a CI/T Trigger Command is offline in the 633 dCDN, or the dCDN is unable to pass a CI/T Command on to any of its 634 cascaded dCDNs: 636 o If the CI/T Command is abandoned by the dCDN, the dCDN SHOULD 637 report an error. 639 o A CI/T "invalidate" command may be reported as "complete" when 640 surrogates that may have the data are offline. In this case, 641 surrogates MUST NOT use the affected data without first 642 revalidating it when they are back online. 644 o CI/T "preposition" and "purge" commands can be reported as 645 "processed" if affected caches are offline and the activity will 646 complete when they return to service. 648 o Otherwise, the dCDN SHOULD keep the Trigger Status Resource in 649 state "pending" or "active" until the CI/T Command is acted upon, 650 or the uCDN chooses to cancel it. 652 4.8. Content URLs 654 To refer to content in the dCDN, the uCDN MUST present URLs in the 655 same form as in the metadata it supplied to the dCDN. By definition, 656 it is always possible for the dCDN to locate content based on URLs in 657 this form. 659 Therefore, if content URLs are transformed by an intermediate CDN in 660 a cascade, that intermediate CDN MUST transform URLs in CI/T Commands 661 it passes to its dCDN. 663 When processing Trigger Specifications, CDNs MUST ignore the URL 664 scheme (http or https) in comparing URLs. For example, for a CI/T 665 invalidate or purge command, content MUST be invalidated or purged 666 regardless of the protocol clients use to request it. 668 5. CI/T Object Properties and Encoding 670 CI/T Commands, Trigger Status Resources and Trigger Collections and 671 their properties are encoded using JSON, as defined in sections 672 Section 5.1.1, Section 5.2.1, and Section 5.1.2. 674 Names in JSON are case sensitive. The names and literal values 675 specified in the present document MUST always use lower-case. 677 JSON types, including 'object', 'array", 'number' and 'string' are 678 defined in [RFC7159]. 680 Unrecognised name/value pairs in JSON objects SHOULD NOT be treated 681 as an error by either the uCDN or dCDN. They SHOULD be ignored in 682 the processing, and passed on by dCDN to any further dCDNs in a 683 cascade. 685 5.1. CI/T Objects 687 The top-level objects defined by the CI/T interface are described in 688 this section. Each has an associated MIME Media Type. The encoding 689 of values used by these objects is described in Section 5.2. 691 5.1.1. CI/T Commands 693 CI/T Commands SHOULD use a MIME Media Type of application/ 694 cdni.ci.TriggerCommand+json. 696 A CI/T Command is encoded as a JSON object containing the following 697 name/value pairs. 699 Name: trigger 701 Description: A specification of the trigger type, and a set of 702 data to act upon. 704 Value: A Trigger Specification, as defined in Section 5.2.1. 706 Mandatory: No, but exactly one of "trigger" or "cancel" MUST be 707 present in a CI/T Command. 709 Name: cancel 711 Description: The URLs of Trigger Status Resources for CI/T 712 Trigger Commands that the uCDN wants to cancel. 714 Value: A non-empty JSON array of URLs represented as JSON 715 strings. 717 Mandatory: No, but exactly one of "trigger" or "cancel" MUST be 718 present in a CI/T Command. 720 Name: cdn-path 722 Description: The CDN Provider Identifiers of CDNs that have 723 already accepted the CI/T Command. 725 Value: A non-empty JSON array of JSON strings, where each 726 string is a CDN Provider Identifier as defined in Section 4.6. 728 Mandatory: Yes. 730 5.1.2. Trigger Status Resource 732 Trigger Status Resources SHOULD use a MIME Media Type of application/ 733 cdni.ci.TriggerStatus+json. 735 A Trigger Status Resource is encoded as a JSON object containing the 736 following name/value pairs. 738 Name: trigger 740 Description: The Trigger Specification posted in the body of 741 the CI/T Command. Note that this need not be a byte-for-byte 742 copy. For example, in the JSON representation the dCDN may re- 743 serialise the information differently. 745 Value: A Trigger Specification, as defined in Section 5.2.1. 747 Mandatory: Yes 749 Name: ctime 751 Description: Time at which the CI/T Command was received by the 752 dCDN. Time is determined by the dCDN, there is no requirement 753 to synchronise clocks between interconnected CDNs. 755 Value: Absolute Time, as defined in Section 5.2.5. 757 Mandatory: Yes 759 Name: mtime 760 Description: Time at which the Trigger Status Resource was last 761 modified. Time is determined by the dCDN, there is no 762 requirement to synchronise clocks between interconnected CDNs. 764 Value: Absolute Time, as defined in Section 5.2.5. 766 Mandatory: Yes 768 Name: etime 770 Description: Estimate of the time at which the dCDN expects to 771 complete the activity. Time is determined by the dCDN, there 772 is no requirement to synchronise clocks between interconnected 773 CDNs. 775 Value: Absolute Time, as defined in Section 5.2.5. 777 Mandatory: No 779 Name: status 781 Description: Current status of the triggered activity. 783 Value: Trigger Status, as defined in Section 5.2.3. 785 Mandatory: Yes 787 Name: errors 789 Description: Descriptions of errors that have occurred while 790 processing a Trigger Command. 792 Value: An array of Error Description, as defined in 793 Section 5.2.6. An empty array is allowed, and equivalent to 794 omitting "errors" from the object. 796 Mandatory: No. 798 5.1.3. Trigger Collection 800 Trigger Collections SHOULD use a MIME Media Type of application/ 801 cdni.ci.TriggerCollection+json. 803 A Trigger Collection is encoded as a JSON object containing the 804 following name/value pairs. 806 Name: triggers 807 Description: Links to Trigger Status Resources in the 808 collection. 810 Value: A JSON array of zero or more URLs, represented as JSON 811 strings. 813 Mandatory: Yes 815 Name: staleresourcetime 817 Description: The length of time for which the dCDN guarantees 818 to keep a completed Trigger Status Resource. After this time, 819 the dCDN SHOULD delete the Trigger Status Resource and all 820 references to it from collections. 822 Value: A JSON number, which must be a positive integer, 823 representing time in seconds. 825 Mandatory: Yes, in the collection of all Trigger Status 826 Resources if the dCDN deletes stale entries. If the property 827 is present in the filtered collections, it MUST have the same 828 value as in the collection of all Trigger Status Resources. 830 Names: coll-all, coll-pending, coll-active, coll-complete, coll- 831 failed 833 Description: Link to a Trigger Collection. 835 Value: A URL represented as a JSON string. 837 Mandatory: Links to all of the filtered collections are 838 mandatory in the collection of all Trigger Status Resources, if 839 the dCDN implements the filtered collections. Otherwise, 840 optional. 842 Name: cdn-id 844 Description: The CDN Provider Identifier of the dCDN. 846 Value: A JSON string, the dCDN's CDN Provider Identifier, as 847 defined in Section 4.6. 849 Mandatory: Only in the collection of all Trigger Status 850 Resources, if the dCDN implements the filtered collections. 851 Optional in the filtered collections (the uCDN can always find 852 the dCDN's cdn-id in the collection of all Trigger Status 853 Resources, but the dCDN can choose to repeat that information 854 in its implementation of filtered collections). 856 5.2. Properties of CI/T Objects 858 This section defines the values that can appear in the top level 859 objects described in Section 5.1, and their encodings. 861 5.2.1. Trigger Specification 863 A Trigger Collection is encoded as a JSON object containing the 864 following name/value pairs. 866 An unrecognised name/value pair in the Trigger Specification object 867 contained in a CI/T Command SHOULD be preserved in the Trigger 868 Specification of any Trigger Status Resource it creates. 870 Name: type 872 Description: This property defines the type of the CI/T Trigger 873 Command. 875 Value: Trigger Type, as defined in Section 5.2.2. 877 Mandatory: Yes 879 Name: metadata.urls 881 Description: The uCDN URLs of the metadata the CI/T Trigger 882 Command applies to. 884 Value: A JSON array of URLs represented as JSON strings. 886 Mandatory: No, but at least one of 'metadata.*' or 'content.*' 887 MUST be present and non-empty. 889 Name: content.urls 891 Description: URLs of content the CI/T Trigger Command applies 892 to, see Section 4.8. 894 Value: A JSON array of URLs represented as JSON strings. 896 Mandatory: No, but at least one of 'metadata.*' or 'content.*' 897 MUST be present and non-empty. 899 Name: content.ccid 901 Description: The Content Collection Identifier of content the 902 trigger applies to. The 'ccid' is a grouping of content, as 903 defined by [I-D.ietf-cdni-metadata]. 905 Value: A JSON array of strings, where each string is a Content 906 Collection Identifier. 908 Mandatory: No, but at least one of 'metadata.*' or 'content.*' 909 MUST be present and non-empty. 911 Name: metadata.patterns 913 Description: The metadata the trigger applies to. 915 Value: A JSON array of Pattern Match, as defined in 916 Section 5.2.4. 918 Mandatory: No, but at least one of 'metadata.*' or 'content.*' 919 MUST be present and non-empty, and metadata.patterns MUST NOT 920 be present if the TriggerType is Preposition. 922 Name: content.patterns 924 Description: The content data the trigger applies to. 926 Value: A JSON array of Pattern Match, as defined in 927 Section 5.2.4. 929 Mandatory: No, but at least one of 'metadata.*' or 'content.*' 930 MUST be present and non-empty, and content.patterns MUST NOT be 931 present if the TriggerType is Preposition. 933 5.2.2. Trigger Type 935 Trigger Type is used in a Trigger Specification to describe trigger 936 action. It MUST be one of the JSON strings in the following table: 938 +-------------+-----------------------------------------------------+ 939 | JSON String | Description | 940 +-------------+-----------------------------------------------------+ 941 | preposition | A request for the dCDN to acquire metadata or | 942 | | content. | 943 | invalidate | A request for the dCDN to invalidate metadata or | 944 | | content. After servicing this request the dCDN will | 945 | | not use the specified data without first re- | 946 | | validating it using, for example, an "If-None- | 947 | | Match" HTTP request. The dCDN need not erase the | 948 | | associated data. | 949 | purge | A request for the dCDN to erase metadata or | 950 | | content. After servicing the request, the specified | 951 | | data MUST NOT be held on the dCDN (the dCDN should | 952 | | re-acquire the metadata or content from uCDN if it | 953 | | needs it). | 954 +-------------+-----------------------------------------------------+ 956 5.2.3. Trigger Status 958 This describes the current status of a Trigger. It MUST be one of 959 the JSON strings in the following table: 961 +------------+------------------------------------------------------+ 962 | JSON | Description | 963 | String | | 964 +------------+------------------------------------------------------+ 965 | pending | The CI/T Trigger Command has not yet been acted | 966 | | upon. | 967 | active | The CI/T Trigger Command is currently being acted | 968 | | upon. | 969 | complete | The CI/T Trigger Command completed successfully. | 970 | processed | The CI/T Trigger Command has been accepted and no | 971 | | further status update will be made (can be used in | 972 | | cases where completion cannot be confirmed). | 973 | failed | The CI/T Trigger Command could not be completed. | 974 | cancelling | Processing of the CI/T Trigger Command is still in | 975 | | progress, but the CI/T Trigger Command has been | 976 | | cancelled by the uCDN. | 977 | cancelled | The CI/T Trigger Command was cancelled by the uCDN. | 978 +------------+------------------------------------------------------+ 980 5.2.4. PatternMatch 982 A Pattern Match consists of a string pattern to match, and flags 983 describing the type of match. 985 It is encoded as a JSON object with the following name/value pairs: 987 Name: pattern 989 Description: A pattern for string matching. 991 Value: A JSON string representing the pattern. The pattern may 992 contain the wildcards * and ?, where * matches any sequence of 993 characters (including the empty string) and ? matches exactly 994 one character. The three literals "\" , "*" and "?" MUST be 995 escaped as "\\", "\*" and "\?". 997 Mandatory: Yes. 999 Name: case-sensitive 1001 Description: Flag indicating whether or not case-sensitive 1002 matching should be used. 1004 Value: One of the JSON values 'true' or 'false'. 1006 Mandatory: No, default is case-insensitive match. 1008 Name: match-query-string 1010 Description: Flag indicating whether or not the query string 1011 should be included in the pattern match. 1013 Value: One of the JSON values 'true' or 'false'. 1015 Mandatory: No, default is not to include the query string in 1016 the pattern match. 1018 Example of case-sensitive prefix match against 1019 "http://www.example.com/trailers/": 1021 { 1022 "pattern": "http://www.example.com/trailers/*", 1023 "case-sensitive": true 1024 } 1026 5.2.5. Absolute Time 1028 A JSON number, seconds since the UNIX epoch. 1030 5.2.6. Error Description 1032 An Error Description is used to report failure of a CI/T Command, or 1033 in the activity it triggered. It is encoded as a JSON object with 1034 the following name/value pairs: 1036 Name: error 1038 Value: Error Code, as defined in Section 5.2.7. 1040 Mandatory: Yes. 1042 Names: metadata.urls, content.urls, metadata.patterns, 1043 content.patterns 1045 Description: Metadata and content references copied from the 1046 Trigger Specification. Only those URLs and patterns to which 1047 the error applies are included in each property, but those URLs 1048 and patterns MUST be exactly as they appear in the request, the 1049 dCDN MUST NOT generalise the URLs. (For example, if the uCDN 1050 requests prepositioning of URLs "http://content.example.com/a" 1051 and "http://content.example.com/b", the dCDN must not 1052 generalise its error report to Pattern 1053 "http://content.example.com/*".) 1055 Value: A JSON array of JSON strings, where each string is 1056 copied from a 'content.*' or 'metadata.*' value in the 1057 corresponding Trigger Specification. 1059 Mandatory: At least one of these name/value pairs is mandatory 1060 in each Error Description object. 1062 Name: description 1064 Description: A human-readable description of the error. 1066 Value: A JSON string, the human-readable description. 1068 Mandatory: No. 1070 5.2.7. Error Code 1072 This type is used by the dCDN to report failures in trigger 1073 processing. 1075 +------------+------------------------------------------------------+ 1076 | Error Code | Description | 1077 +------------+------------------------------------------------------+ 1078 | emeta | The dCDN was unable to acquire metadata required to | 1079 | | fulfil the request. | 1080 | econtent | The dCDN was unable to acquire content (CT/T | 1081 | | preposition commands only). | 1082 | eperm | The uCDN does not have permission to issue the CI/T | 1083 | | Command (for example, the data is owned by another | 1084 | | CDN). | 1085 | ereject | The dCDN is not willing to fulfil the CI/T Command | 1086 | | (for example, a preposition request for content at a | 1087 | | time when the dCDN would not accept Request Routing | 1088 | | requests from the uCDN). | 1089 | ecdn | An internal error in the dCDN or one of its | 1090 | | downstream CDNs. | 1091 | ecancelled | The uCDN cancelled the request. | 1092 +------------+------------------------------------------------------+ 1094 5.3. Formalization of the JSON Data 1096 The JSON data described in this document has been formalised using 1097 CDDL [I-D.greevenbosch-appsawg-cbor-cddl] as follows: 1099 CIT-object = CIT-command / Trigger-Status-Resource / Trigger-Collection 1101 CIT-command ; use media type application/cdni.ci.TriggerCommand+json 1102 = { 1103 ? trigger: Triggerspec 1104 ? cancel: [* URI] 1105 cdn-path: [* Cdn-PID] 1106 } 1108 Trigger-Status-Resource ; application/cdni.ci.TriggerStatus+json. 1109 = { 1110 trigger: Triggerspec 1111 ctime: Absolute-Time 1112 mtime: Absolute-Time 1113 ? etime: Absolute-Time 1114 status: Trigger-Status 1115 ? errors: [* Error-Description] 1116 } 1118 Trigger-Collection ; application/cdni.ci.TriggerCollection+json 1119 = { 1120 triggers: [* URI] 1121 ? staleresourcetime: int ; time in seconds 1122 ? coll-all: URI 1123 ? coll-pending: URI 1124 ? coll-active: URI 1125 ? coll-complete: URI 1126 ? coll-failed: URI 1127 ? cdn-id: Cdn-PID 1128 } 1130 Triggerspec = { ; 5.2.1 1131 type: Trigger-Type 1132 ? metadata.urls: [* URI] 1133 ? content.urls: [* URI] 1134 ? content.ccid: [* Ccid] 1135 ? metadata.patterns: [* Pattern-Match] 1136 ? content.patterns: [* Pattern-Match] 1137 } 1139 Trigger-Type = "preposition" / "invalidate" / "purge" ; 5.2.2 1141 Trigger-Status = "pending" / "active" / "complete" / "processed" 1142 / "failed" / "cancelling" / "cancelled" ; 5.2.3 1144 Pattern-Match = { ; 5.2.4 1145 pattern: tstr 1146 ? case-sensitive: bool 1147 ? match-query-string: bool 1148 } 1150 Absolute-Time = number ; seconds since UNIX epoch, 5.2.5 1152 Error-Description = { ; 5.2.6 1153 error: Error-Code 1154 ? metadata.urls: [* URI] 1155 ? content.urls: [* URI] 1156 ? metadata.patterns: [* Pattern-Match] 1157 ? content.patterns: [* Pattern-Match] 1158 ? description: tstr 1159 } 1161 Error-Code = "emeta" / "econtent" / "eperm" / "ereject" 1162 / "ecdn" / "ecancelled" ; 5.2.7 1164 Ccid = tstr ; see I-D.ietf-cdni-metadata 1166 Cdn-PID = tstr .regexp "AS[0-9]+:[0-9]+" 1168 URI = tstr 1170 6. Examples 1172 The following sections provide examples of different CI/T objects 1173 encoded as JSON. 1175 Discovery of the triggers interface is out of scope of this document. 1176 In an implementation, all CI/T URLs are under the control of the 1177 dCDN. The uCDN MUST NOT attempt to ascribe any meaning to individual 1178 elements of the path. 1180 In examples in this section, the URL 'http://dcdn.example.com/ 1181 triggers' is used as the location of the collection of all Trigger 1182 Status Resources, and the CDN Provider Id of uCDN is "AS64496:1". 1184 6.1. Creating Triggers 1186 Examples of the uCDN triggering activity in the dCDN: 1188 6.1.1. Preposition 1190 An example of a CI/T preposition command, a POST to the collection of 1191 all Trigger Status Resources. 1193 Note that "metadata.patterns" and "content.patterns" are not allowed 1194 in a preposition Trigger Specification. 1196 REQUEST: 1198 POST /triggers HTTP/1.1 1199 User-Agent: example-user-agent/0.1 1200 Host: dcdn.example.com 1201 Accept: */* 1202 Content-Type: application/cdni.ci.TriggerCommand+json 1203 Content-Length: 347 1205 { 1206 "trigger" : { 1207 "type": "preposition", 1209 "metadata.urls" : [ "http://metadata.example.com/a/b/c" ], 1210 "content.urls" : [ 1211 "http://www.example.com/a/b/c/1", 1212 "http://www.example.com/a/b/c/2", 1213 "http://www.example.com/a/b/c/3", 1214 "http://www.example.com/a/b/c/4" 1215 ] 1216 }, 1217 "cdn-path" : [ "AS64496:1" ] 1219 } 1221 RESPONSE: 1223 HTTP/1.1 201 Created 1224 Date: Sun, 31 Aug 2014 09:53:18 GMT 1225 Content-Length: 472 1226 Content-Type: application/cdni.ci.TriggerStatus+json 1227 Location: http://dcdn.example.com/triggers/0 1228 Server: example-server/0.1 1230 { 1231 "ctime": 1409478798, 1232 "etime": 1409478806, 1233 "mtime": 1409478798, 1234 "status": "pending", 1235 "trigger": { 1236 "content.urls": [ 1237 "http://www.example.com/a/b/c/1", 1238 "http://www.example.com/a/b/c/2", 1239 "http://www.example.com/a/b/c/3", 1240 "http://www.example.com/a/b/c/4" 1241 ], 1242 "metadata.urls": [ 1243 "http://metadata.example.com/a/b/c" 1244 ], 1245 "type": "preposition" 1246 } 1247 } 1249 6.1.2. Invalidate 1251 An example of a CI/T invalidate command, another POST to the 1252 collection of all Trigger Status Resources. This instructs the dCDN 1253 to re-validate the content at "http://www.example.com/a/index.html", 1254 as well as any metadata and content whose URLs are prefixed by 1255 "http://metadata.example.com/a/b/" using case-insensitive matching, 1256 and "http://www.example.com/a/b/" respectively, using case-sensitive 1257 matching. 1259 REQUEST: 1261 POST /triggers HTTP/1.1 1262 User-Agent: example-user-agent/0.1 1263 Host: dcdn.example.com 1264 Accept: */* 1265 Content-Type: application/cdni.ci.TriggerCommand+json 1266 Content-Length: 384 1267 { 1268 "trigger" : { 1269 "type": "invalidate", 1271 "metadata.patterns" : [ 1272 { "pattern" : "http://metadata.example.com/a/b/*" } 1273 ], 1275 "content.urls" : [ "http://www.example.com/a/index.html" ], 1276 "content.patterns" : [ 1277 { "pattern" : "http://www.example.com/a/b/*", 1278 "case-sensitive" : true 1279 } 1280 ] 1281 }, 1282 "cdn-path" : [ "AS64496:1" ] 1283 } 1285 RESPONSE: 1287 HTTP/1.1 201 Created 1288 Date: Sun, 31 Aug 2014 09:53:19 GMT 1289 Content-Length: 551 1290 Content-Type: application/cdni.ci.TriggerStatus+json 1291 Location: http://dcdn.example.com/triggers/1 1292 Server: example-server/0.1 1294 { 1295 "ctime": 1409478799, 1296 "etime": 1409478807, 1297 "mtime": 1409478799, 1298 "status": "pending", 1299 "trigger": { 1300 "content.patterns": [ 1301 { 1302 "case-sensitive": true, 1303 "pattern": "http://www.example.com/a/b/*" 1304 } 1305 ], 1306 "content.urls": [ 1307 "http://www.example.com/a/index.html" 1308 ], 1309 "metadata.patterns": [ 1310 { 1311 "pattern": "http://metadata.example.com/a/b/*" 1312 } 1313 ], 1314 "type": "invalidate" 1316 } 1317 } 1319 6.2. Examining Trigger Status 1321 Once Trigger Status Resources have been created, the uCDN can check 1322 their status as shown in these examples. 1324 6.2.1. Collection of All Triggers 1326 The uCDN can fetch the collection of all Trigger Status Resources it 1327 has created that have not yet been deleted or removed as expired. 1328 After creation of the "preposition" and "invalidate" triggers shown 1329 above, this collection might look as follows: 1331 REQUEST: 1333 GET /triggers HTTP/1.1 1334 User-Agent: example-user-agent/0.1 1335 Host: dcdn.example.com 1336 Accept: */* 1338 RESPONSE: 1340 HTTP/1.1 200 OK 1341 Content-Length: 347 1342 Expires: Sun, 31 Aug 2014 09:54:19 GMT 1343 Server: example-server/0.1 1344 Etag: "-6516741166528256414" 1345 Cache-Control: max-age=60 1346 Date: Sun, 31 Aug 2014 09:53:19 GMT 1347 Content-Type: application/cdni.ci.TriggerCollection+json 1349 { 1350 "cdn-id": "AS64496:0", 1351 "coll-active": "/triggers/active", 1352 "coll-complete": "/triggers/complete", 1353 "coll-failed": "/triggers/failed", 1354 "coll-pending": "/triggers/pending", 1355 "staleresourcetime": 86400, 1356 "triggers": [ 1357 "http://dcdn.example.com/triggers/0", 1358 "http://dcdn.example.com/triggers/1" 1359 ] 1360 } 1362 6.2.2. Filtered Collections of Trigger Status Resources 1364 The filtered collections are also available to the uCDN. Before the 1365 dCDN starts processing the two CI/T Trigger Commands shown above, 1366 both will appear in the collection of Pending Triggers, for example: 1368 REQUEST: 1370 GET /triggers/pending HTTP/1.1 1371 User-Agent: example-user-agent/0.1 1372 Host: dcdn.example.com 1373 Accept: */* 1375 RESPONSE: 1377 HTTP/1.1 200 OK 1378 Content-Length: 153 1379 Expires: Sun, 31 Aug 2014 09:54:19 GMT 1380 Server: example-server/0.1 1381 Etag: "5012053611544832286" 1382 Cache-Control: max-age=60 1383 Date: Sun, 31 Aug 2014 09:53:19 GMT 1384 Content-Type: application/cdni.ci.TriggerCollection+json 1386 { 1387 "staleresourcetime": 86400, 1388 "triggers": [ 1389 "http://dcdn.example.com/triggers/0", 1390 "http://dcdn.example.com/triggers/1" 1391 ] 1392 } 1394 At this point, if no other Trigger Status Resources had been created, 1395 the other filtered views would be empty. For example: 1397 REQUEST: 1399 GET /triggers/complete HTTP/1.1 1400 User-Agent: example-user-agent/0.1 1401 Host: dcdn.example.com 1402 Accept: */* 1404 RESPONSE: 1406 HTTP/1.1 200 OK 1407 Content-Length: 56 1408 Expires: Sun, 31 Aug 2014 09:54:19 GMT 1409 Server: example-server/0.1 1410 Etag: "2986340333785000363" 1411 Cache-Control: max-age=60 1412 Date: Sun, 31 Aug 2014 09:53:19 GMT 1413 Content-Type: application/cdni.ci.TriggerCollection+json 1415 { 1416 "staleresourcetime": 86400, 1417 "triggers": [] 1418 } 1420 6.2.3. Individual Trigger Status Resources 1422 The Trigger Status Resources can also be examined for detail about 1423 individual CI/T Trigger Commands. For example, for the CI/T 1424 "preposition" and "invalidate" commands from previous examples: 1426 REQUEST: 1428 GET /triggers/0 HTTP/1.1 1429 User-Agent: example-user-agent/0.1 1430 Host: dcdn.example.com 1431 Accept: */* 1433 RESPONSE: 1435 HTTP/1.1 200 OK 1436 Content-Length: 472 1437 Expires: Sun, 31 Aug 2014 09:54:19 GMT 1438 Server: example-server/0.1 1439 Etag: "-4765587034697674779" 1440 Cache-Control: max-age=60 1441 Date: Sun, 31 Aug 2014 09:53:19 GMT 1442 Content-Type: application/cdni.ci.TriggerStatus+json 1444 { 1445 "ctime": 1409478798, 1446 "etime": 1409478806, 1447 "mtime": 1409478798, 1448 "status": "pending", 1449 "trigger": { 1450 "content.urls": [ 1451 "http://www.example.com/a/b/c/1", 1452 "http://www.example.com/a/b/c/2", 1453 "http://www.example.com/a/b/c/3", 1454 "http://www.example.com/a/b/c/4" 1455 ], 1456 "metadata.urls": [ 1457 "http://metadata.example.com/a/b/c" 1458 ], 1459 "type": "preposition" 1460 } 1461 } 1463 REQUEST: 1465 GET /triggers/1 HTTP/1.1 1466 User-Agent: example-user-agent/0.1 1467 Host: dcdn.example.com 1468 Accept: */* 1470 RESPONSE: 1472 HTTP/1.1 200 OK 1473 Content-Length: 551 1474 Expires: Sun, 31 Aug 2014 09:54:19 GMT 1475 Server: example-server/0.1 1476 Etag: "-7657333837290433420" 1477 Cache-Control: max-age=60 1478 Date: Sun, 31 Aug 2014 09:53:19 GMT 1479 Content-Type: application/cdni.ci.TriggerStatus+json 1481 { 1482 "ctime": 1409478799, 1483 "etime": 1409478807, 1484 "mtime": 1409478799, 1485 "status": "pending", 1486 "trigger": { 1487 "content.patterns": [ 1488 { 1489 "case-sensitive": true, 1490 "pattern": "http://www.example.com/a/b/*" 1491 } 1492 ], 1493 "content.urls": [ 1494 "http://www.example.com/a/index.html" 1495 ], 1496 "metadata.patterns": [ 1497 { 1498 "pattern": "http://metadata.example.com/a/b/*" 1499 } 1500 ], 1501 "type": "invalidate" 1502 } 1503 } 1505 6.2.4. Polling for Change 1507 The uCDN SHOULD use the Entity Tags of collections or Trigger Status 1508 Resources when polling for change in status, as shown in the 1509 following examples: 1511 REQUEST: 1513 GET /triggers/pending HTTP/1.1 1514 User-Agent: example-user-agent/0.1 1515 Host: dcdn.example.com 1516 Accept: */* 1517 If-None-Match: "5012053611544832286" 1519 RESPONSE: 1521 HTTP/1.1 304 Not Modified 1522 Content-Length: 0 1523 Expires: Sun, 31 Aug 2014 09:54:19 GMT 1524 Server: example-server/0.1 1525 Etag: "5012053611544832286" 1526 Cache-Control: max-age=60 1527 Date: Sun, 31 Aug 2014 09:53:19 GMT 1528 Content-Type: application/cdni.ci.TriggerCollection+json 1530 REQUEST: 1532 GET /triggers/0 HTTP/1.1 1533 User-Agent: example-user-agent/0.1 1534 Host: dcdn.example.com 1535 Accept: */* 1536 If-None-Match: "-4765587034697674779" 1538 RESPONSE: 1540 HTTP/1.1 304 Not Modified 1541 Content-Length: 0 1542 Expires: Sun, 31 Aug 2014 09:54:19 GMT 1543 Server: example-server/0.1 1544 Etag: "-4765587034697674779" 1545 Cache-Control: max-age=60 1546 Date: Sun, 31 Aug 2014 09:53:19 GMT 1547 Content-Type: application/cdni.ci.TriggerStatus+json 1549 When the CI/T Trigger Command is complete, the contents of the 1550 filtered collections will be updated along with their Entity Tags. 1551 For example, when the two example CI/T Trigger Commands are complete, 1552 the collections of pending and complete Trigger Status Resources 1553 might look like: 1555 REQUEST: 1557 GET /triggers/pending HTTP/1.1 1558 User-Agent: example-user-agent/0.1 1559 Host: dcdn.example.com 1560 Accept: */* 1561 If-None-Match: "5012053611544832286" 1563 RESPONSE: 1565 HTTP/1.1 200 OK 1566 Content-Length: 56 1567 Expires: Sun, 31 Aug 2014 09:54:29 GMT 1568 Server: example-server/0.1 1569 Etag: "-4471185573414616962" 1570 Cache-Control: max-age=60 1571 Date: Sun, 31 Aug 2014 09:53:29 GMT 1572 Content-Type: application/cdni.ci.TriggerCollection+json 1574 { 1575 "staleresourcetime": 86400, 1576 "triggers": [] 1577 } 1579 REQUEST: 1581 GET /triggers/complete HTTP/1.1 1582 User-Agent: example-user-agent/0.1 1583 Host: dcdn.example.com 1584 Accept: */* 1585 If-None-Match: "2986340333785000363" 1587 RESPONSE: 1589 HTTP/1.1 200 OK 1590 Content-Length: 153 1591 Expires: Sun, 31 Aug 2014 09:54:30 GMT 1592 Server: example-server/0.1 1593 Etag: "-1508172875796647067" 1594 Cache-Control: max-age=60 1595 Date: Sun, 31 Aug 2014 09:53:30 GMT 1596 Content-Type: application/cdni.ci.TriggerCollection+json 1598 { 1599 "staleresourcetime": 86400, 1600 "triggers": [ 1601 "http://dcdn.example.com/triggers/0", 1602 "http://dcdn.example.com/triggers/1" 1603 ] 1604 } 1606 6.2.5. Deleting Trigger Status Resources 1608 The dCDN can delete completed and failed Trigger Status Resources to 1609 reduce the size of the collections. For example, to delete the 1610 "preposition" request from earlier examples: 1612 REQUEST: 1614 DELETE /triggers/0 HTTP/1.1 1615 User-Agent: example-user-agent/0.1 1616 Host: dcdn.example.com 1617 Accept: */* 1619 RESPONSE: 1621 HTTP/1.1 204 No Content 1622 Date: Sun, 31 Aug 2014 09:53:30 GMT 1623 Content-Length: 0 1624 Content-Type: text/html; charset=UTF-8 1625 Server: example-server/0.1 1627 This would, for example, cause the collection of completed Trigger 1628 Status Resources shown in the example above to be updated to: 1630 REQUEST: 1632 GET /triggers/complete HTTP/1.1 1633 User-Agent: example-user-agent/0.1 1634 Host: dcdn.example.com 1635 Accept: */* 1637 RESPONSE: 1639 HTTP/1.1 200 OK 1640 Content-Length: 106 1641 Expires: Sun, 31 Aug 2014 09:54:30 GMT 1642 Server: example-server/0.1 1643 Etag: "-1842390246836476263" 1644 Cache-Control: max-age=60 1645 Date: Sun, 31 Aug 2014 09:53:30 GMT 1646 Content-Type: application/cdni.ci.TriggerCollection+json 1648 { 1649 "staleresourcetime": 86400, 1650 "triggers": [ 1651 "http://dcdn.example.com/triggers/1" 1652 ] 1653 } 1655 6.2.6. Error Reporting 1657 In this example the uCDN has requested prepositioning of 1658 "http://newsite.example.com/index.html", but the dCDN was unable to 1659 locate metadata for that site: 1661 REQUEST: 1663 GET /triggers/2 HTTP/1.1 1664 User-Agent: example-user-agent/0.1 1665 Host: dcdn.example.com 1666 Accept: */* 1668 RESPONSE: 1670 HTTP/1.1 200 OK 1671 Content-Length: 505 1672 Expires: Sun, 31 Aug 2014 09:54:38 GMT 1673 Server: example-server/0.1 1674 Etag: "-3893590191073700822" 1675 Cache-Control: max-age=60 1676 Date: Sun, 31 Aug 2014 09:53:38 GMT 1677 Content-Type: application/cdni.ci.TriggerStatus+json 1679 { 1680 "ctime": 1409478810, 1681 "errors": [ 1682 { 1683 "content.urls": [ 1684 "http://newsite.example.com/index.html" 1685 ], 1686 "description": 1687 "No HostIndex entry found for newsite.example.com", 1688 "error": "emeta" 1689 } 1690 ], 1691 "etime": 1409478818, 1692 "mtime": 1409478814, 1693 "status": "active", 1694 "trigger": { 1695 "content.urls": [ 1696 "http://newsite.example.com/index.html" 1697 ], 1698 "type": "preposition" 1699 } 1700 } 1702 7. IANA Considerations 1704 7.1. Media type registrations 1706 7.1.1. CI/T Commands 1708 The MIME media type for CI/T Commands is application/ 1709 cdni.ci.TriggerCommand+json. 1711 Type Name: application 1713 Subtype name: cdni.ci.TriggerCommand+json 1715 Required parameters: N/A 1717 Optional parameters: N/A 1719 Encoding considerations: binary 1721 Security Considerations: See [RFCthis], Section 8 1723 Interoperability Considerations: Described in [RFCthis] 1725 Published Specification: [RFCthis] 1727 Applications that use this media type: No known applications 1728 currently use this media type. 1730 Additional Information: 1732 Deprecated alias names for this type: N/A 1734 Magic number(s): N/A 1736 File Extensions: N/A 1738 Macintosh file type code(s): TEXT 1740 Person & email address to contact for further information: IESG 1741 1743 Intended Usage: COMMON 1745 Restrictions on usage: None 1747 Author: Rob Murray 1749 Change controller: IESG 1750 Note: No "charset" parameter is defined for this registration because 1751 a charset parameter is not defined for application/json [RFC7159]. 1753 7.1.2. CI/T Trigger Status Resource 1755 The MIME media type for CI/T Trigger Status Resources is application/ 1756 cdni.ci.TriggerStatus+json. 1758 Type Name: application 1760 Subtype name: cdni.ci.TriggerStatus+json 1762 Required parameters: N/A 1764 Optional parameters: N/A 1766 Encoding considerations: binary 1768 Security Considerations: See [RFCthis], Section 8 1770 Interoperability Considerations: Described in [RFCthis] 1772 Published Specification: [RFCthis] 1774 Applications that use this media type: No known applications 1775 currently use this media type. 1777 Additional Information: 1779 Deprecated alias names for this type: N/A 1781 Magic number(s): N/A 1783 File Extensions: N/A 1785 Macintosh file type code(s): TEXT 1787 Person & email address to contact for further information: IESG 1788 1790 Intended Usage: COMMON 1792 Restrictions on usage: None 1794 Author: Rob Murray 1796 Change controller: IESG 1797 Note: No "charset" parameter is defined for this registration because 1798 a charset parameter is not defined for application/json [RFC7159]. 1800 7.1.3. CI/T Trigger Collection 1802 The MIME media type for CI/T Trigger Collections is application/ 1803 cdni.ci.TriggerCollection+json. 1805 Type Name: application 1807 Subtype name: cdni.ci.TriggerCollection+json 1809 Required parameters: N/A 1811 Optional parameters: N/A 1813 Encoding considerations: binary 1815 Security Considerations: See [RFCthis], Section 8 1817 Interoperability Considerations: Described in [RFCthis] 1819 Published Specification: [RFCthis] 1821 Applications that use this media type: No known applications 1822 currently use this media type. 1824 Additional Information: 1826 Deprecated alias names for this type: N/A 1828 Magic number(s): N/A 1830 File Extensions: N/A 1832 Macintosh file type code(s): TEXT 1834 Person & email address to contact for further information: IESG 1835 1837 Intended Usage: COMMON 1839 Restrictions on usage: None 1841 Author: Rob Murray 1843 Change controller: IESG 1844 Note: No "charset" parameter is defined for this registration because 1845 a charset parameter is not defined for application/json [RFC7159]. 1847 8. Security Considerations 1849 The CI/T interface provides a mechanism to allow a uCDN to generate 1850 requests into the dCDN and to inspect its own CI/T requests and their 1851 current state. The CI/T interface does not allow access to or 1852 modification of the uCDN or dCDN metadata relating to content 1853 delivery, or to the content itself. It can only control the presence 1854 of that metadata in the dCDN, and the processing work and network 1855 utilisation involved in ensuring that presence. 1857 By examining pre-positioning requests to a dCDN, and correctly 1858 interpreting content and metadata URLs, an attacker could learn the 1859 uCDN or content owner's predictions for future content popularity. 1860 By examining invalidate or purge requests, an attacker could learn 1861 about changes in the content owner's catalogue. 1863 By injecting CI/T commands an attacker, or a misbehaving uCDN, would 1864 generate work in the dCDN and uCDN as they process those requests. 1865 And so would a man in the middle attacker modifying valid CI/T 1866 commands generated by the uCDN. In both cases, that would decrease 1867 the dCDN caching efficiency by causing it to unnecessarily acquire or 1868 re-acquire content metadata and/or content. 1870 A dCDN implementation of CI/T MUST restrict the actions of a uCDN to 1871 the data corresponding to that uCDN. Failure to do so would allow 1872 uCDNs to detrimentally affect each other's efficiency by generating 1873 unnecessary acquisition or re-acquisition load. 1875 8.1. Authentication, Authorization, Confidentiality, Integrity 1876 Protection 1878 A CI/T implementation MUST support TLS transport for HTTP (https) as 1879 per [RFC2818]. 1881 The use of TLS for transport of the CI/T interface allows: 1883 o The dCDN and the uCDN to authenticate each other. 1885 and, once they have mutually authenticated each other, it allows: 1887 o The dCDN and the uCDN to authorize each other (to ensure they are 1888 receiving CI/T Commands from, or reporting status to, an 1889 authorized CDN). 1891 o CDNI commands and responses to transmitted with confidentiality, 1892 In an environment where any such protection is required, the use of a 1893 mutually authenticated encrypted transport MUST be used to ensure 1894 confidentiality of the CI/T information. TLS MUST be used by CI/T, 1895 including authentication of the remote end. 1897 The general TLS usage guidance in [RFC7525] SHOULD be followed. 1899 HTTP requests that attempt to access or operate on CI/T data 1900 belonging to another CDN MUST be rejected using, for example, HTTP 1901 "403 Forbidden" or "404 Not Found". This is intended to prevent 1902 unauthorised users from generating unnecessary load in dCDN or uCDN 1903 due to revalidation, reacquisition, or unnecessary acquisition. 1905 Note that in a "diamond" configuration, where one uCDN's content can 1906 be acquired via more than one directly-connected uCDN, it may not be 1907 possible for the dCDN to determine from which uCDN it acquired 1908 content. In this case, the dCDN MUST allow each uCDN from which the 1909 content could have been acquired to act upon that content using CI/T 1910 Commands. 1912 8.2. Denial of Service 1914 This document does not define a specific mechanism to protect against 1915 Denial of Service (DoS) attacks on the CI/T. However, CI/T endpoints 1916 can be protected against DoS attacks through the use of TLS transport 1917 and/or via mechanisms outside the scope of the CI/T interface, such 1918 as firewalling or use of Virtual Private Networks (VPNs). 1920 Depending on the implementation, triggered activity may consume 1921 significant processing and bandwidth in the dCDN. A malicious or 1922 faulty uCDN could use this to generate unnecessary load in the dCDN. 1923 The dCDN should consider mechanisms to avoid overload, for example by 1924 rate-limiting acceptance or processing of CI/T Commands, or batching 1925 up its processing. 1927 8.3. Privacy 1929 The CI/T protocol does not carry any information about individual End 1930 Users of a CDN, there are no privacy concerns for End Users. 1932 The CI/T protocol does carry information which could be considered 1933 commercially sensitive by CDN operators and content owners. The use 1934 of mutually authenticated TLS to establish a secure session for the 1935 transport of CI/T data, as discussed in Section 8.1, provides 1936 confidentiality while the CI/T data is in transit, and prevents 1937 parties other party than the authorised dCDN from gaining access to 1938 that data. The dCDN MUST ensure that it only exposes CI/T data 1939 related to a uCDN to clients it has authenticated as belonging to 1940 that uCDN. 1942 9. Acknowledgements 1944 The authors thank Kevin Ma for his input, and Carsten Bormann for his 1945 review and formalization of the JSON data. 1947 10. References 1949 10.1. Normative References 1951 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1952 Requirement Levels", BCP 14, RFC 2119, March 1997. 1954 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 1955 Interchange Format", RFC 7159, March 2014. 1957 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1958 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 1960 [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1961 (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. 1963 10.2. Informative References 1965 [I-D.greevenbosch-appsawg-cbor-cddl] 1966 Vigano, C., Birkholz, H., and R. Sun, "CBOR data 1967 definition language: a notational convention to express 1968 CBOR data structures.", draft-greevenbosch-appsawg-cbor- 1969 cddl-05 (work in progress), March 2015. 1971 [I-D.ietf-cdni-metadata] 1972 Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1973 "CDN Interconnection Metadata", draft-ietf-cdni- 1974 metadata-09 (work in progress), March 2015. 1976 [I-D.ietf-cdni-redirection] 1977 Niven-Jenkins, B. and R. Brandenburg, "Request Routing 1978 Redirection Interface for CDN Interconnection", draft- 1979 ietf-cdni-redirection-09 (work in progress), April 2015. 1981 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1983 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1984 Distribution Network Interconnection (CDNI) Problem 1985 Statement", RFC 6707, September 2012. 1987 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, 1988 "Framework for Content Distribution Network 1989 Interconnection (CDNI)", RFC 7336, August 2014. 1991 [RFC7337] Leung, K. and Y. Lee, "Content Distribution Network 1992 Interconnection (CDNI) Requirements", RFC 7337, August 1993 2014. 1995 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1996 "Recommendations for Secure Use of Transport Layer 1997 Security (TLS) and Datagram Transport Layer Security 1998 (DTLS)", BCP 195, RFC 7525, May 2015. 2000 Authors' Addresses 2002 Rob Murray 2003 Velocix (Alcatel-Lucent) 2004 3 Ely Road 2005 Milton, Cambridge CB24 6DD 2006 UK 2008 Email: rob.murray@alcatel-lucent.com 2010 Ben Niven-Jenkins 2011 Velocix (Alcatel-Lucent) 2012 3 Ely Road 2013 Milton, Cambridge CB24 6DD 2014 UK 2016 Email: ben.niven-jenkins@alcatel-lucent.com