Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8007

Content Delivery Network Interconnection (CDNI) Control Interface / Triggers

Pages: 49
Proposed Standard
Errata
Part 2 of 2 – Pages 27 to 49
First   Prev   None

Top   ToC   RFC8007 - Page 27   prevText

6. Examples

The following subsections provide examples of different CI/T objects encoded as JSON. Discovery of the CI/T interface is out of scope for this document. In an implementation, all CI/T URLs are under the control of the dCDN. The uCDN MUST NOT attempt to ascribe any meaning to individual elements of the path. In examples in this section, the URL "https://dcdn.example.com/ triggers" is used as the location of the collection of all Trigger Status Resources, and the CDN PID of the uCDN is "AS64496:1".
Top   ToC   RFC8007 - Page 28

6.1. Creating Triggers

Examples of the uCDN triggering activity in the dCDN:

6.1.1. Preposition

Below is an example of a CI/T "preposition" command -- a POST to the collection of all Trigger Status Resources. Note that "metadata.patterns" and "content.patterns" are not allowed in a pre-position Trigger Specification. REQUEST: POST /triggers HTTP/1.1 User-Agent: example-user-agent/0.1 Host: dcdn.example.com Accept: */* Content-Type: application/cdni; ptype=ci-trigger-command Content-Length: 352 { "trigger": { "type": "preposition", "metadata.urls": [ "https://metadata.example.com/a/b/c" ], "content.urls": [ "https://www.example.com/a/b/c/1", "https://www.example.com/a/b/c/2", "https://www.example.com/a/b/c/3", "https://www.example.com/a/b/c/4" ] }, "cdn-path": [ "AS64496:1" ] }
Top   ToC   RFC8007 - Page 29
   RESPONSE:

     HTTP/1.1 201 Created
     Date: Wed, 04 May 2016 08:48:10 GMT
     Content-Length: 467
     Content-Type: application/cdni; ptype=ci-trigger-status
     Location: https://dcdn.example.com/triggers/0
     Server: example-server/0.1

     {
         "ctime": 1462351690,
         "etime": 1462351698,
         "mtime": 1462351690,
         "status": "pending",
         "trigger": {
             "content.urls": [
                 "https://www.example.com/a/b/c/1",
                 "https://www.example.com/a/b/c/2",
                 "https://www.example.com/a/b/c/3",
                 "https://www.example.com/a/b/c/4"
             ],
             "metadata.urls": [
                 "https://metadata.example.com/a/b/c"
             ],
             "type": "preposition"
         }
     }
Top   ToC   RFC8007 - Page 30

6.1.2. Invalidate

Below is an example of a CI/T "invalidate" command -- another POST to the collection of all Trigger Status Resources. This instructs the dCDN to revalidate the content at "https://www.example.com/a/ index.html", as well as any metadata and content whose URLs are prefixed by "https://metadata.example.com/a/b/" using case-insensitive matching, and "https://www.example.com/a/b/" using case-sensitive matching, respectively. REQUEST: POST /triggers HTTP/1.1 User-Agent: example-user-agent/0.1 Host: dcdn.example.com Accept: */* Content-Type: application/cdni; ptype=ci-trigger-command Content-Length: 387 { "trigger": { "type": "invalidate", "metadata.patterns": [ { "pattern": "https://metadata.example.com/a/b/*" } ], "content.urls": [ "https://www.example.com/a/index.html" ], "content.patterns": [ { "pattern": "https://www.example.com/a/b/*", "case-sensitive": true } ] }, "cdn-path": [ "AS64496:1" ] }
Top   ToC   RFC8007 - Page 31
   RESPONSE:

     HTTP/1.1 201 Created
     Date: Wed, 04 May 2016 08:48:11 GMT
     Content-Length: 545
     Content-Type: application/cdni; ptype=ci-trigger-status
     Location: https://dcdn.example.com/triggers/1
     Server: example-server/0.1

     {
         "ctime": 1462351691,
         "etime": 1462351699,
         "mtime": 1462351691,
         "status": "pending",
         "trigger": {
             "content.patterns": [
                 {
                     "case-sensitive": true,
                     "pattern": "https://www.example.com/a/b/*"
                 }
             ],
             "content.urls": [
                 "https://www.example.com/a/index.html"
             ],
             "metadata.patterns": [
                 {
                     "pattern": "https://metadata.example.com/a/b/*"
                 }
             ],
             "type": "invalidate"
         }
     }
Top   ToC   RFC8007 - Page 32

6.2. Examining Trigger Status

Once Trigger Status Resources have been created, the uCDN can check their status as shown in the following examples.

6.2.1. Collection of All Triggers

The uCDN can fetch the collection of all Trigger Status Resources it has created that have not yet been deleted or removed as expired. After creation of the "preposition" and "invalidate" triggers shown above, this collection might look as follows: REQUEST: GET /triggers HTTP/1.1 User-Agent: example-user-agent/0.1 Host: dcdn.example.com Accept: */* RESPONSE: HTTP/1.1 200 OK Content-Length: 341 Expires: Wed, 04 May 2016 08:49:11 GMT Server: example-server/0.1 ETag: "-936094426920308378" Cache-Control: max-age=60 Date: Wed, 04 May 2016 08:48:11 GMT Content-Type: application/cdni; ptype=ci-trigger-collection { "cdn-id": "AS64496:0", "coll-active": "/triggers/active", "coll-complete": "/triggers/complete", "coll-failed": "/triggers/failed", "coll-pending": "/triggers/pending", "staleresourcetime": 86400, "triggers": [ "https://dcdn.example.com/triggers/0", "https://dcdn.example.com/triggers/1" ] }
Top   ToC   RFC8007 - Page 33

6.2.2. Filtered Collections of Trigger Status Resources

The filtered collections are also available to the uCDN. Before the dCDN starts processing the two CI/T Trigger Commands shown above, both will appear in the collection of pending triggers. For example: REQUEST: GET /triggers/pending HTTP/1.1 User-Agent: example-user-agent/0.1 Host: dcdn.example.com Accept: */* RESPONSE: HTTP/1.1 200 OK Content-Length: 152 Expires: Wed, 04 May 2016 08:49:11 GMT Server: example-server/0.1 ETag: "4331492443626270781" Cache-Control: max-age=60 Date: Wed, 04 May 2016 08:48:11 GMT Content-Type: application/cdni; ptype=ci-trigger-collection { "staleresourcetime": 86400, "triggers": [ "https://dcdn.example.com/triggers/0", "https://dcdn.example.com/triggers/1" ] } At this point, if no other Trigger Status Resources had been created, the other filtered views would be empty. For example: REQUEST: GET /triggers/complete HTTP/1.1 User-Agent: example-user-agent/0.1 Host: dcdn.example.com Accept: */*
Top   ToC   RFC8007 - Page 34
   RESPONSE:

     HTTP/1.1 200 OK
     Content-Length: 54
     Expires: Wed, 04 May 2016 08:49:11 GMT
     Server: example-server/0.1
     ETag: "7958041393922269003"
     Cache-Control: max-age=60
     Date: Wed, 04 May 2016 08:48:11 GMT
     Content-Type: application/cdni; ptype=ci-trigger-collection

     {
         "staleresourcetime": 86400,
         "triggers": []
     }

6.2.3. Individual Trigger Status Resources

The Trigger Status Resources can also be examined for details about individual CI/T Trigger Commands. For example, for the CI/T "preposition" and "invalidate" commands from previous examples: REQUEST: GET /triggers/0 HTTP/1.1 User-Agent: example-user-agent/0.1 Host: dcdn.example.com Accept: */*
Top   ToC   RFC8007 - Page 35
   RESPONSE:

     HTTP/1.1 200 OK
     Content-Length: 467
     Expires: Wed, 04 May 2016 08:49:10 GMT
     Server: example-server/0.1
     ETag: "6990548174277557683"
     Cache-Control: max-age=60
     Date: Wed, 04 May 2016 08:48:10 GMT
     Content-Type: application/cdni; ptype=ci-trigger-status

     {
         "ctime": 1462351690,
         "etime": 1462351698,
         "mtime": 1462351690,
         "status": "pending",
         "trigger": {
             "content.urls": [
                 "https://www.example.com/a/b/c/1",
                 "https://www.example.com/a/b/c/2",
                 "https://www.example.com/a/b/c/3",
                 "https://www.example.com/a/b/c/4"
             ],
             "metadata.urls": [
                 "https://metadata.example.com/a/b/c"
             ],
             "type": "preposition"
         }
     }

   REQUEST:

     GET /triggers/1 HTTP/1.1
     User-Agent: example-user-agent/0.1
     Host: dcdn.example.com
     Accept: */*

   RESPONSE:

     HTTP/1.1 200 OK
     Content-Length: 545
     Expires: Wed, 04 May 2016 08:49:11 GMT
     Server: example-server/0.1
     ETag: "-554385204989405469"
     Cache-Control: max-age=60
     Date: Wed, 04 May 2016 08:48:11 GMT
     Content-Type: application/cdni; ptype=ci-trigger-status
Top   ToC   RFC8007 - Page 36
     {
         "ctime": 1462351691,
         "etime": 1462351699,
         "mtime": 1462351691,
         "status": "pending",
         "trigger": {
             "content.patterns": [
                 {
                     "case-sensitive": true,
                     "pattern": "https://www.example.com/a/b/*"
                 }
             ],
             "content.urls": [
                 "https://www.example.com/a/index.html"
             ],
             "metadata.patterns": [
                 {
                     "pattern": "https://metadata.example.com/a/b/*"
                 }
             ],
             "type": "invalidate"
         }
     }

6.2.4. Polling for Changes in Status

The uCDN SHOULD use the ETags of collections or Trigger Status Resources when polling for changes in status, as shown in the following examples: REQUEST: GET /triggers/pending HTTP/1.1 User-Agent: example-user-agent/0.1 Host: dcdn.example.com Accept: */* If-None-Match: "4331492443626270781" RESPONSE: HTTP/1.1 304 Not Modified Content-Length: 0 Expires: Wed, 04 May 2016 08:49:11 GMT Server: example-server/0.1 ETag: "4331492443626270781" Cache-Control: max-age=60 Date: Wed, 04 May 2016 08:48:11 GMT Content-Type: application/cdni; ptype=ci-trigger-collection
Top   ToC   RFC8007 - Page 37
   REQUEST:

     GET /triggers/0 HTTP/1.1
     User-Agent: example-user-agent/0.1
     Host: dcdn.example.com
     Accept: */*
     If-None-Match: "6990548174277557683"

   RESPONSE:

     HTTP/1.1 304 Not Modified
     Content-Length: 0
     Expires: Wed, 04 May 2016 08:49:10 GMT
     Server: example-server/0.1
     ETag: "6990548174277557683"
     Cache-Control: max-age=60
     Date: Wed, 04 May 2016 08:48:10 GMT
     Content-Type: application/cdni; ptype=ci-trigger-status

   When the CI/T Trigger Command is complete, the contents of the
   filtered collections will be updated along with their ETags.  For
   example, when the two example CI/T Trigger Commands are complete, the
   collections of pending and complete Trigger Status Resources might
   look like:

   REQUEST:

     GET /triggers/pending HTTP/1.1
     User-Agent: example-user-agent/0.1
     Host: dcdn.example.com
     Accept: */*

   RESPONSE:

     HTTP/1.1 200 OK
     Content-Length: 54
     Expires: Wed, 04 May 2016 08:49:15 GMT
     Server: example-server/0.1
     ETag: "1337503181677633762"
     Cache-Control: max-age=60
     Date: Wed, 04 May 2016 08:48:15 GMT
     Content-Type: application/cdni; ptype=ci-trigger-collection

     {
         "staleresourcetime": 86400,
         "triggers": []
     }
Top   ToC   RFC8007 - Page 38
   REQUEST:

     GET /triggers/complete HTTP/1.1
     User-Agent: example-user-agent/0.1
     Host: dcdn.example.com
     Accept: */*

   RESPONSE:

     HTTP/1.1 200 OK
     Content-Length: 152
     Expires: Wed, 04 May 2016 08:49:22 GMT
     Server: example-server/0.1
     ETag: "4481489539378529796"
     Cache-Control: max-age=60
     Date: Wed, 04 May 2016 08:48:22 GMT
     Content-Type: application/cdni; ptype=ci-trigger-collection

     {
         "staleresourcetime": 86400,
         "triggers": [
             "https://dcdn.example.com/triggers/0",
             "https://dcdn.example.com/triggers/1"
         ]
     }

6.2.5. Deleting Trigger Status Resources

The uCDN can delete completed and failed Trigger Status Resources to reduce the size of the collections, as described in Section 4.4. For example, to delete the "preposition" request from earlier examples: REQUEST: DELETE /triggers/0 HTTP/1.1 User-Agent: example-user-agent/0.1 Host: dcdn.example.com Accept: */* RESPONSE: HTTP/1.1 204 No Content Date: Wed, 04 May 2016 08:48:22 GMT Content-Length: 0 Content-Type: text/html; charset=UTF-8 Server: example-server/0.1
Top   ToC   RFC8007 - Page 39
   This would, for example, cause the collection of completed Trigger
   Status Resources shown in the example above to be updated to:

   REQUEST:

     GET /triggers/complete HTTP/1.1
     User-Agent: example-user-agent/0.1
     Host: dcdn.example.com
     Accept: */*

   RESPONSE:

     HTTP/1.1 200 OK
     Content-Length: 105
     Expires: Wed, 04 May 2016 08:49:22 GMT
     Server: example-server/0.1
     ETag: "-6938620031669085677"
     Cache-Control: max-age=60
     Date: Wed, 04 May 2016 08:48:22 GMT
     Content-Type: application/cdni; ptype=ci-trigger-collection

     {
         "staleresourcetime": 86400,
         "triggers": [
             "https://dcdn.example.com/triggers/1"
         ]
     }

6.2.6. Error Reporting

In this example, the uCDN has requested pre-positioning of "https://newsite.example.com/index.html", but the dCDN was unable to locate metadata for that site: REQUEST: GET /triggers/2 HTTP/1.1 User-Agent: example-user-agent/0.1 Host: dcdn.example.com Accept: */*
Top   ToC   RFC8007 - Page 40
   RESPONSE:

     HTTP/1.1 200 OK
     Content-Length: 486
     Expires: Wed, 04 May 2016 08:49:26 GMT
     Server: example-server/0.1
     ETag: "5182824839919043757"
     Cache-Control: max-age=60
     Date: Wed, 04 May 2016 08:48:26 GMT
     Content-Type: application/cdni; ptype=ci-trigger-status

     {
         "ctime": 1462351702,
         "errors": [
             {
                 "content.urls": [
                     "https://newsite.example.com/index.html"
                 ],
                 "description": "newsite.example.com not in HostIndex",
                 "error": "emeta"
             }
         ],
         "etime": 1462351710,
         "mtime": 1462351706,
         "status": "active",
         "trigger": {
             "content.urls": [
                 "https://newsite.example.com/index.html"
             ],
             "type": "preposition"
         }
     }

7. IANA Considerations

7.1. CDNI Payload Type Parameter Registrations

The IANA is requested to register the following new Payload Types in the "CDNI Payload Types" registry defined by [RFC7736], for use with the "application/cdni" MIME media type. +-----------------------+---------------+ | Payload Type | Specification | +-----------------------+---------------+ | ci-trigger-command | RFC 8007 | | ci-trigger-status | RFC 8007 | | ci-trigger-collection | RFC 8007 | +-----------------------+---------------+
Top   ToC   RFC8007 - Page 41

7.2. "CDNI CI/T Trigger Types" Registry

The IANA is requested to create a new "CDNI CI/T Trigger Types" subregistry under the "Content Delivery Network Interconnection (CDNI) Parameters" registry. Additions to the "CDNI CI/T Trigger Types" registry will be made via the RFC Required policy as defined in [RFC5226]. The initial contents of the "CDNI CI/T Trigger Types" registry comprise the names and descriptions listed in Section 5.2.2 of this document, with this document acting as the specification.

7.3. "CDNI CI/T Error Codes" Registry

The IANA is requested to create a new "CDNI CI/T Error Codes" subregistry under the "Content Delivery Network Interconnection (CDNI) Parameters" registry. Additions to the "CDNI CI/T Error Codes" registry will be made via the Specification Required policy as defined in [RFC5226]. The Designated Expert will verify that new Error Code registrations do not duplicate existing Error Code definitions (in name or functionality), prevent gratuitous additions to the namespace, and prevent any additions to the namespace that would impair the interoperability of CDNI implementations. The initial contents of the "CDNI CI/T Error Codes" registry comprise the names and descriptions of the Error Codes listed in Section 5.2.7 of this document, with this document acting as the specification.

8. Security Considerations

The CI/T interface provides a mechanism to allow a uCDN to generate requests into the dCDN and to inspect its own CI/T requests and their current states. The CI/T interface does not allow access to, or modification of, the uCDN or dCDN metadata relating to content delivery or to the content itself. It can only control the presence of that metadata in the dCDN, and the processing work and network utilization involved in ensuring that presence. By examining "preposition" requests to a dCDN, and correctly interpreting content and metadata URLs, an attacker could learn the uCDN's or content owner's predictions for future content popularity. By examining "invalidate" or "purge" requests, an attacker could learn about changes in the content owner's catalog.
Top   ToC   RFC8007 - Page 42
   By injecting CI/T Commands, an attacker or a misbehaving uCDN would
   generate work in the dCDN and uCDN as they process those requests.
   So would a man-in-the-middle attacker modifying valid CI/T Commands
   generated by the uCDN.  In both cases, that would decrease the dCDN's
   caching efficiency by causing it to unnecessarily acquire or
   reacquire content metadata and/or content.

   A dCDN implementation of CI/T MUST restrict the actions of a uCDN to
   the data corresponding to that uCDN.  Failure to do so would allow
   uCDNs to detrimentally affect each other's efficiency by generating
   unnecessary acquisition or reacquisition load.

   An origin that chooses to delegate its delivery to a CDN is trusting
   that CDN to deliver content on its behalf; the interconnection of
   CDNs is an extension of that trust to dCDNs.  That trust relationship
   is a commercial arrangement, outside the scope of the CDNI protocols.
   So, while a malicious CDN could deliberately generate load on a dCDN
   using the CI/T interface, the protocol does not otherwise attempt to
   address malicious behavior between interconnected CDNs.

8.1. Authentication, Authorization, Confidentiality, Integrity Protection

A CI/T implementation MUST support Transport Layer Security (TLS) transport for HTTP (HTTPS) as per [RFC2818] and [RFC7230]. TLS MUST be used by the server side (dCDN) and the client side (uCDN) of the CI/T interface, including authentication of the remote end, unless alternate methods are used for ensuring the security of the information in the CI/T interface requests and responses (such as setting up an IPsec tunnel between the two CDNs or using a physically secured internal network between two CDNs that are owned by the same corporate entity). The use of TLS for transport of the CI/T interface allows the dCDN and the uCDN to authenticate each other using TLS client authentication and TLS server authentication.
Top   ToC   RFC8007 - Page 43
   Once the dCDN and the uCDN have mutually authenticated each other,
   TLS allows:

   o  The dCDN and the uCDN to authorize each other (to ensure that they
      are receiving CI/T Commands from, or reporting status to, an
      authorized CDN).

   o  CDNI commands and responses to be transmitted with
      confidentiality.

   o  Protection of the integrity of CDNI commands and responses.

   When TLS is used, the general TLS usage guidance in [RFC7525] MUST be
   followed.

   The mechanisms for access control are dCDN-specific and are not
   standardized as part of this CI/T specification.

   HTTP requests that attempt to access or operate on CI/T data
   belonging to another CDN MUST be rejected using, for example,
   HTTP 403 ("Forbidden") or 404 ("Not Found").  This is intended to
   prevent unauthorized users from generating unnecessary load in dCDNs
   or uCDNs due to revalidation, reacquisition, or unnecessary
   acquisition.

   When deploying a network of interconnected CDNs, the possible
   inefficiencies related to the diamond configuration discussed in
   Section 2.2.1 should be considered.

8.2. Denial of Service

This document does not define a specific mechanism to protect against Denial-of-Service (DoS) attacks on the CI/T interface. However, CI/T endpoints can be protected against DoS attacks through the use of TLS transport and/or via mechanisms outside the scope of the CI/T interface, such as firewalling or the use of Virtual Private Networks (VPNs). Depending on the implementation, triggered activity may consume significant processing and bandwidth in the dCDN. A malicious or faulty uCDN could use this to generate unnecessary load in the dCDN. The dCDN should consider mechanisms to avoid overload -- for example, by rate-limiting acceptance or processing of CI/T Commands, or by performing batch processing.
Top   ToC   RFC8007 - Page 44

8.3. Privacy

The CI/T protocol does not carry any information about individual end users of a CDN; there are no privacy concerns for end users. The CI/T protocol does carry information that could be considered commercially sensitive by CDN operators and content owners. The use of mutually authenticated TLS to establish a secure session for the transport of CI/T data, as discussed in Section 8.1, provides confidentiality while the CI/T data is in transit and prevents parties other than the authorized dCDN from gaining access to that data. The dCDN MUST ensure that it only exposes CI/T data related to a uCDN to clients it has authenticated as belonging to that uCDN.

9. References

9.1. Normative References

[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, <http://www.rfc-editor.org/info/rfc1930>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, DOI 10.17487/RFC6707, September 2012, <http://www.rfc-editor.org/info/rfc6707>.
Top   ToC   RFC8007 - Page 45
   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, DOI 10.17487/RFC7159,
              March 2014, <http://www.rfc-editor.org/info/rfc7159>.

   [RFC7230]  Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
              Transfer Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

   [RFC7231]  Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
              Transfer Protocol (HTTP/1.1): Semantics and Content",
              RFC 7231, DOI 10.17487/RFC7231, June 2014,
              <http://www.rfc-editor.org/info/rfc7231>.

   [RFC7232]  Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
              Transfer Protocol (HTTP/1.1): Conditional Requests",
              RFC 7232, DOI 10.17487/RFC7232, June 2014,
              <http://www.rfc-editor.org/info/rfc7232>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525,
              May 2015, <http://www.rfc-editor.org/info/rfc7525>.

   [RFC8006]  Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
              "Content Delivery Network Interconnection (CDNI)
              Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016,
              <http://www.rfc-editor.org/info/rfc8006>.

9.2. Informative References

[CBOR-CDDL] Vigano, C. and H. Birkholz, "CBOR data definition language (CDDL): a notational convention to express CBOR data structures", Work in Progress, draft-greevenbosch-appsawg-cbor-cddl-09, September 2016. [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., "Framework for Content Distribution Network Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, August 2014, <http://www.rfc-editor.org/info/rfc7336>. [RFC7337] Leung, K., Ed., and Y. Lee, Ed., "Content Distribution Network Interconnection (CDNI) Requirements", RFC 7337, DOI 10.17487/RFC7337, August 2014, <http://www.rfc-editor.org/info/rfc7337>.
Top   ToC   RFC8007 - Page 46
   [RFC7736]  Ma, K., "Content Delivery Network Interconnection (CDNI)
              Media Type Registration", RFC 7736, DOI 10.17487/RFC7736,
              December 2015, <http://www.rfc-editor.org/info/rfc7736>.

   [RFC7975]  Niven-Jenkins, B., Ed., and R. van Brandenburg, Ed.,
              "Request Routing Redirection Interface for Content
              Delivery Network (CDN) Interconnection", RFC 7975,
              DOI 10.17487/RFC7975, October 2016,
              <http://www.rfc-editor.org/info/rfc7975>.
Top   ToC   RFC8007 - Page 47

Appendix A. Formalization of the JSON Data

This appendix is non-normative. The JSON data described in this document has been formalized using the CBOR Data Definition Language (CDDL) [CBOR-CDDL] (where "CBOR" means "Concise Binary Object Representation"), as follows: CIT-object = CIT-command / Trigger-Status-Resource / Trigger-Collection CIT-command ; use media type application/cdni; ptype=ci-trigger-command = { ? trigger: Triggerspec ? cancel: [* URI] cdn-path: [* Cdn-PID] } Trigger-Status-Resource ; application/cdni; ptype=ci-trigger-status = { trigger: Triggerspec ctime: Absolute-Time mtime: Absolute-Time ? etime: Absolute-Time status: Trigger-Status ? errors: [* Error-Description] } Trigger-Collection ; application/cdni; ptype=ci-trigger-collection = { triggers: [* URI] ? staleresourcetime: int ; time in seconds ? coll-all: URI ? coll-pending: URI ? coll-active: URI ? coll-complete: URI ? coll-failed: URI ? cdn-id: Cdn-PID } Triggerspec = { ; see Section 5.2.1 type: Trigger-Type ? metadata.urls: [* URI] ? content.urls: [* URI] ? content.ccid: [* Ccid] ? metadata.patterns: [* Pattern-Match] ? content.patterns: [* Pattern-Match] }
Top   ToC   RFC8007 - Page 48
 Trigger-Type = "preposition" / "invalidate"
    / "purge" ; see Section 5.2.2

 Trigger-Status = "pending" / "active" / "complete" / "processed"
    / "failed" / "cancelling" / "cancelled" ; see Section 5.2.3

 Pattern-Match = { ; see Section 5.2.4
   pattern: tstr
   ? case-sensitive: bool
   ? match-query-string: bool
 }

 Absolute-Time = number ; seconds since UNIX epoch (Section 5.2.5)

 Error-Description = { ; see Section 5.2.6
   error: Error-Code
   ? metadata.urls: [* URI]
   ? content.urls: [* URI]
   ? metadata.patterns: [* Pattern-Match]
   ? content.patterns: [* Pattern-Match]
   ? description: tstr
 }

 Error-Code = "emeta" / "econtent" / "eperm" / "ereject"
    / "ecdn" / "ecanceled"  ; see Section 5.2.7

 Ccid = tstr ; see RFC 8006

 Cdn-PID = tstr .regexp "AS[0-9]+:[0-9]+"

 URI = tstr
Top   ToC   RFC8007 - Page 49

Acknowledgments

The authors thank Kevin Ma for his input, and Carsten Bormann for his review and formalization of the JSON data.

Authors' Addresses

Rob Murray Nokia 3 Ely Road Milton, Cambridge CB24 6DD United Kingdom Email: rob.murray@nokia.com Ben Niven-Jenkins Nokia 3 Ely Road Milton, Cambridge CB24 6DD United Kingdom Email: ben.niven-jenkins@nokia.com