draft-ietf-cdni-triggers-extensions-04.txt   draft-ietf-cdni-triggers-extensions-05.txt 
Network Working Group O. Finkelman Network Working Group O. Finkelman
Internet-Draft Qwilt Internet-Draft Qwilt
Updates: 8007 (if approved) S. Mishra Updates: 8007 (if approved) S. Mishra
Intended status: Standards Track Verizon Intended status: Standards Track Verizon
Expires: September 22, 2020 March 21, 2020 Expires: March 22, 2021 September 18, 2020
CDNI Control Triggers Interface Extensions CDNI Control Triggers Interface Extensions
draft-ietf-cdni-triggers-extensions-04 draft-ietf-cdni-triggers-extensions-05
Abstract Abstract
This document updates RFC 8007 to include generic extensions and more This document updates RFC 8007 to include generic extensions and more
granular content matching options, required by the Open Caching granular content matching options, required by the Open Caching
architecture. The Open Caching working group of the Streaming Video architecture. The Open Caching working group of the Streaming Video
Alliance is focused on the delegation of video delivery request from Alliance is focused on the delegation of video delivery request from
commercial Content Delivery Networks (CDNs) to a caching layer at the commercial CDNs to a caching layer at the ISP. In that aspect, Open
ISP. In that aspect, Open Caching is a specific use case of Content Caching is a specific use case of CDNI, where the commercial CDN is
Delivery Networks Interconnection (CDNI), where the commercial CDN is
the upstream CDN (uCDN) and the ISP caching layer is the downstream the upstream CDN (uCDN) and the ISP caching layer is the downstream
CDN (dCDN). The extensions specified in this document to the CDNI CDN (dCDN). The extensions specified in this document to the CDNI
Control Interface / Triggers are derived from requirements of Open Control Interface / Triggers are derived from requirements of Open
Caching but are applicable to CDNI use cases in general. Caching but are applicable to CDNI use cases in general.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"OPTIONAL" in this document are to be interpreted as described in BCP document are to be interpreted as described in RFC 2119 [RFC2119].
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2020. This Internet-Draft will expire on March 22, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 44 skipping to change at page 3, line 44
10.2. Informative References . . . . . . . . . . . . . . . . . 41 10.2. Informative References . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
This document defines the objects and extensions required for This document defines the objects and extensions required for
granular content management operations. For that purpose it extends granular content management operations. For that purpose it extends
CDNI Control Interface / Triggers [RFC8007] by adding new content CDNI Control Interface / Triggers [RFC8007] by adding new content
selection options to the trigger specification and specifying a selection options to the trigger specification and specifying a
generic extension mechanism that enables adding future functions for generic extension mechanism that enables adding future functions for
controlling the trigger execution. This document also defines an controlling the trigger execution. This document also defines and
initial set of extension objects and provides examples for the initial set of extension objects. This document gives examples for
extensions. For full and complete examples of the trigger interface the extensions specified herein, for complete examples of the trigger
usage please see Section 6 of [RFC8007]. interface usage see Section 6 of [RFC8007].
The CDNI Metadata Interface is described in [RFC8006]. The CDNI Metadata Interface is described in [RFC8006].
The CDNI Footprint and Capability Interface is described in The CDNI Footprint and Capability Interface is described in
[RFC8008]. [RFC8008].
The CDNI Control Interface / Triggers is described in [RFC8007]. The CDNI Control Interface / Triggers is described in [RFC8007].
1.1. Terminology 1.1. Terminology
skipping to change at page 7, line 47 skipping to change at page 7, line 47
Section 5.1.1 of [RFC8007]. Section 5.1.1 of [RFC8007].
o Trigger Status Resource v2: A trigger status resource response o Trigger Status Resource v2: A trigger status resource response
using the payload type ci-trigger-status.v2. Version 2 MUST only using the payload type ci-trigger-status.v2. Version 2 MUST only
use "trigger.v2" objects as defined in Section 3.3.1, instead of a use "trigger.v2" objects as defined in Section 3.3.1, instead of a
"trigger" object, as well as "errors.v2" array as defined in "trigger" object, as well as "errors.v2" array as defined in
Section 3.3.6, instead of a "errors" array. All other properties Section 3.3.6, instead of a "errors" array. All other properties
of the trigger status v2 are as defined in Section 5.1.2 of of the trigger status v2 are as defined in Section 5.1.2 of
[RFC8007]. The errors array "errors.v2" is a list of all errors [RFC8007]. The errors array "errors.v2" is a list of all errors
that occurred in any of the downstream CDNs along the execution that occurred in any of the downstream CDNs along the execution
path. When a downstream CDN,for example, dCDN-A, propagates a path. When a downstream CDN, dCDN-A, propagates a trigger to
trigger to another downstream CDN, say dCDN-B, it MUST also another downstream CDN, dCDN-B, it MUST also propagated back all
propagate back all errors reported by dCDN-B in the trigger status errors reported by dCDN-B in the trigger status resource and add
resource and add them to its own trigger status resource. them to its own trigger status resource.
o Trigger Collections: The payload type ci-trigger-collection is o Trigger Collections: The payload type ci-trigger-collection is
used with no changes and as defined in 5.1.3 of [RFC8007]. used with no changes and as defined in 5.1.3 of [RFC8007].
Usage example of version 2 of trigger command Usage example of version 2 of trigger command
REQUEST: REQUEST:
POST /triggers HTTP/1.1 POST /triggers HTTP/1.1
User-Agent: example-user-agent/0.1 User-Agent: example-user-agent/0.1
skipping to change at page 10, line 7 skipping to change at page 10, line 7
extension object. As extension objects are expected to be added extension object. As extension objects are expected to be added
to the interface as new requirements comes along, it is expected to the interface as new requirements comes along, it is expected
that in some cases a dCDN may receive a trigger that it cannot that in some cases a dCDN may receive a trigger that it cannot
process or does not understand. It is essential for the trigger process or does not understand. It is essential for the trigger
caller to be able to understand when such errors occur so they can caller to be able to understand when such errors occur so they can
take actions to fix them. This document adds a mechanism to take actions to fix them. This document adds a mechanism to
report extension errors. report extension errors.
o Error propagation - enable the uCDN to traceback an error to the o Error propagation - enable the uCDN to traceback an error to the
dCDN in which it occurred. CDNI triggers may be propagated over a dCDN in which it occurred. CDNI triggers may be propagated over a
chain of downstream CDNs. For example, an upstream CDN, call it chain of downstream CDNs. Let us take for example an upstream
uCDN-A, that is delegating to a downstream CDN, call it dCDN-B. (uCDN-A) CDN A that is delegating to a downstream CDN B (dCDN-B)
And, dCDN-B is delegating to a downstream CDN, call it, dCDN-C. and dCDN-B is delegating to a downstream CDN C (dCDN-C). Triggers
In this example, triggers sent from uCDN-A to dCDN-B may be sent from uCDN-A to dCDN-B may be redistributed from dCDN-B to
redistributed from dCDN-B to dCDN-C and errors can happen anywhere dCDN-C and errors can happen anywhere along the path. Therefore,
along the path. Therefore, it is essential for uCDN-A that sets it is essential for uCDN-A that sets the trigger, to be able to
the trigger, to be able to trace back an error to the downstream trace back an error to the downstream CDN where it occurred. This
CDN where it occurred. This document adds a mechanism to document adds a mechanism to propagate the ID of the faulty dCDN
propagate the ID of the faulty dCDN back to the uCDN by adding the back to the uCDN by adding the CDN ID to the error description.
CDN ID to the error description. When a downstream dCDN (dCDN-B) When a downstream dCDN-B propagates a trigger to another
propagates a trigger to another downstream CDN (dCDN-C), it MUST downstream dCDN-C, it MUST also propagate back the errors received
also propagate back the errors received in the trigger status in the trigger status resource from dCDN-C by adding them to the
resource from dCDN-C by adding them to the errors array in its own errors array in its own status resource to be sent back to the
status resource to be sent back to the originating CDN, in this originating uCDN-A. This makes sure that the trigger originating
example, the uCDN-A. This makes sure that the trigger originating upstream CDN will receive an array of errors that occurred in all
in an upstream CDN will receive an array of errors that occurred the CDNs along the execution path, each error carrying its own CDN
in all the downstream CDNs along the execution path, each error identifier.
carrying its own CDN identifier.
3.3. Properties of CI/T Version 2 objects 3.3. Properties of CI/T Version 2 objects
This section defines the values that can appear in the top-level This section defines the values that can appear in the top-level
objects described in Section 3.1, and their encodings. objects described in Section 3.1, and their encodings.
3.3.1. Trigger Specification Version 2 3.3.1. Trigger Specification Version 2
Version 2 of the Trigger Specification adds the following properties Version 2 of the Trigger Specification adds the following properties
on top of the existing properties of the trigger specification on top of the existing properties of the trigger specification
skipping to change at page 15, line 8 skipping to change at page 15, line 8
position command might be executed in suboptimal times for some position command might be executed in suboptimal times for some
geographies if transparently redistributed, but it might still work. geographies if transparently redistributed, but it might still work.
Redistribution safety MUST be specified for each Redistribution safety MUST be specified for each
GenericTriggerExtension property. If a CDN does not understand or GenericTriggerExtension property. If a CDN does not understand or
support a given GenericTriggerExtension property that is not safe-to- support a given GenericTriggerExtension property that is not safe-to-
redistribute, the CDN MUST set the "incomprehensible" flag to true redistribute, the CDN MUST set the "incomprehensible" flag to true
for that GenericTriggerExtension object before redistributing it. for that GenericTriggerExtension object before redistributing it.
The "incomprehensible" flag signals to a dCDN that trigger metadata The "incomprehensible" flag signals to a dCDN that trigger metadata
was not properly transformed by the tCDN. A CDN MUST NOT attempt to was not properly transformed by the tCDN. A CDN MUST NOT attempt to
execute a trigger that has been marked as "incomprehensible" by a execute a trigger with an extension that has been marked as
uCDN. "incomprehensible" by a uCDN.
tCDNs MUST NOT change the value of mandatory-to-enforce or safe-to- tCDNs MUST NOT change the value of mandatory-to-enforce or safe-to-
redistribute when propagating a trigger to a dCDN. Although a tCDN redistribute when propagating a trigger to a dCDN. Although a tCDN
can set the value of "incomprehensible" to true, a tCDN MUST NOT can set the value of "incomprehensible" to true, a tCDN MUST NOT
change the value of "incomprehensible" from true to false. change the value of "incomprehensible" from true to false.
Table 1 describes the action to be taken by a tCDN for the different Table 1 describes the action to be taken by a tCDN for the different
combinations of mandatory-to-enforce ("MtE") and safe-to-redistribute combinations of mandatory-to-enforce ("MtE") and safe-to-redistribute
("StR") properties when the tCDN either does or does not understand ("StR") properties when the tCDN either does or does not understand
the trigger extension object in question: the trigger extension object in question:
skipping to change at page 16, line 39 skipping to change at page 16, line 39
| | | | "incomprehensible" to true when | | | | | "incomprehensible" to true when |
| | | | redistributing. | | | | | redistributing. |
| True | False | False | MUST NOT serve. MUST set | | True | False | False | MUST NOT serve. MUST set |
| | | | "incomprehensible" to true when | | | | | "incomprehensible" to true when |
| | | | redistributing. | | | | | redistributing. |
+-------+-------+------------+--------------------------------------+ +-------+-------+------------+--------------------------------------+
Table 1: Action to be taken by a tCDN for the different combinations Table 1: Action to be taken by a tCDN for the different combinations
of MtE and StR properties of MtE and StR properties
Table 2 describes the action to be taken by a tCDN for the different Table 2 describes the action to be taken by a dCDN for the different
combinations of mandatory-to-enforce and "incomprehensible" combinations of mandatory-to-enforce and "incomprehensible"
("Incomp") properties, when the dCDN either does or does not ("Incomp") properties, when the dCDN either does or does not
understand the trigger extension object in question: understand the trigger extension object in question:
+-------+--------+---------------+----------------------------------+ +-------+--------+---------------+----------------------------------+
| MtE | Incomp | Extension | Trigger action | | MtE | Incomp | Extension | Trigger action |
| | | object | | | | | object | |
| | | understood by | | | | | understood by | |
| | | dCDN | | | | | dCDN | |
+-------+--------+---------------+----------------------------------+ +-------+--------+---------------+----------------------------------+
skipping to change at page 19, line 26 skipping to change at page 19, line 26
3.3.6. Error Description Version 2 3.3.6. Error Description Version 2
Version 2 of the Error Description adds the "content.playlists", Version 2 of the Error Description adds the "content.playlists",
"content.regexs", "extensions" and "cdn" properties on top of the "content.regexs", "extensions" and "cdn" properties on top of the
existing properties of version 1 of the trigger Error Description as existing properties of version 1 of the trigger Error Description as
defined in Section 5.2.6 of [RFC8007]. defined in Section 5.2.6 of [RFC8007].
Properties: content.regexs, content.playlists Properties: content.regexs, content.playlists
Description: Content Regex and Playlist references are copied Description: Content Regex and Playlist references copied from
from the Trigger Specification. Only those regexs and the Trigger Specification. Only those regexs and playlists to
playlists to which the error applies are included in each which the error applies are included in each property, but
property, but those references MUST be exactly as they appear those references MUST be exactly as they appear in the request;
in the request; the dCDN MUST NOT change or generalize the URLs the dCDN MUST NOT change or generalize the URLs or Regexs.
or Regexs. Note that these properties are added on top of the Note that these properties are added on top of the already
already existing properties: "metadata.urls", "content.urls", existing properties: "metadata.urls", "content.urls",
"metadata.patterns" and "content.patterns". "metadata.patterns" and "content.patterns".
Type: A JSON array of JSON strings, where each string is copied Type: A JSON array of JSON strings, where each string is copied
from a "content.regexs" or "content.playlists" value in the from a "content.regexs" or "content.playlists" value in the
corresponding Trigger Specification. corresponding Trigger Specification.
Mandatory: At least one of "content.regexs", Mandatory: At least one of "content.regexs",
"content.playlists", "metadata.urls", "content.urls", "content.playlists", "metadata.urls", "content.urls",
"metadata.patterns" or "content.patterns" is mandatory in each "metadata.patterns" or "content.patterns" is mandatory in each
Error Description object. Error Description object.
Property: extensions Property: extensions
Description: Array of trigger extension objects copied from the Description: Array of trigger extension objects copied from the
corresponding "extensions" array from the Trigger corresponding "extensions" array from the Trigger
Specification. Only those extensions to which the error Specification. Only those extensions to which the error
applies are included, but those extensions MUST be exactly as applies are included, but those extensions MUST be exactly as
they appear in the request. where each object is copied from they appear in the request.
data copied from the
Type: Array of GenericTriggerExtension objects, where each Type: Array of GenericTriggerExtension objects, where each
extension object is copied from the "extensions" array values extension object is copied from the "extensions" array values
in the Trigger Specification. in the Trigger Specification.
Mandatory: No. The "extensions" array SHOULD be used only if Mandatory: No. The "extensions" array SHOULD be used only if
there were errors related to extension objects. the error relates to extension objects.
Property: cdn Property: cdn
Description: The CDN PID of the CDN where the error occurred. Description: The CDN PID of the CDN where the error occurred.
The "cdn" property is used by the originating uCDN or by The "cdn" property is used by the originating uCDN or by
propagating dCDN in order to distinguish in which CDN the error propagating dCDN in order to distinguish in which CDN the error
occured. occured.
Type: A non-empty JSON string, where the string is a CDN PID as Type: A non-empty JSON string, where the string is a CDN PID as
defined in Section 4.6 of [RFC8007]. defined in Section 4.6 of [RFC8007].
skipping to change at page 24, line 30 skipping to change at page 24, line 30
} }
3.4.3. Extensions with Error Propagation 3.4.3. Extensions with Error Propagation
In the following example a CI/T "preposition" command is using two In the following example a CI/T "preposition" command is using two
extensions to control the way the trigger is executed. In this extensions to control the way the trigger is executed. In this
example the receiving dCDN identified as "AS64500:0" does not support example the receiving dCDN identified as "AS64500:0" does not support
the first extension in the extensions array. dCDN "AS64500:0" further the first extension in the extensions array. dCDN "AS64500:0" further
distributes this trigger to another downstream CDN that is identified distributes this trigger to another downstream CDN that is identified
as "AS64501:0", which does not support the second extension in the as "AS64501:0", which does not support the second extension in the
extensions array. The error is propagated from "AS64501:0" to extensions array. The error is propagate from "AS64501:0" to
"AS64500:0" and the errors.v2 array reflects both errors. "AS64500:0" and the errors.v2 array reflects both errors.
REQUEST: REQUEST:
POST /triggers HTTP/1.1 POST /triggers HTTP/1.1
User-Agent: example-user-agent/0.1 User-Agent: example-user-agent/0.1
Host: triggers.dcdn.example.com Host: triggers.dcdn.example.com
Accept: */* Accept: */*
Content-Type: application/cdni; ptype=ci-trigger-command.v2 Content-Type: application/cdni; ptype=ci-trigger-command.v2
{ {
skipping to change at page 28, line 46 skipping to change at page 28, line 46
A uCDN may wish to perform content management operations on the dCDN A uCDN may wish to perform content management operations on the dCDN
in a specific schedule. The TimePolicy extensions allows the uCDN to in a specific schedule. The TimePolicy extensions allows the uCDN to
instruct the dCDN to execute the trigger command in a desired time instruct the dCDN to execute the trigger command in a desired time
window. For example, a content provider that wishes to pre-populate window. For example, a content provider that wishes to pre-populate
a new episode at off-peak time so that it would be ready on caches at a new episode at off-peak time so that it would be ready on caches at
prime time when the episode is released for viewing. A scheduled prime time when the episode is released for viewing. A scheduled
operation enables the uCDN to direct the dCDN in what time frame to operation enables the uCDN to direct the dCDN in what time frame to
execute the trigger. execute the trigger.
A uCDN may wish to schedule a trigger such that the dCDN will execute A uCDN may wish to to schedule a trigger such that the dCDN will
it in local time, as it is measured in each region. For example, a execute it in local time, as it is measured in each region. For
uCDN may wish the dCDN to pull the content at off-peak hours, between example, a uCDN may wish the dCDN to pull the content at off-peak
2AM-4AM, however, as a CDN is distributed across multiple time zones, hours, between 2AM-4AM, however, as a CDN is distributed across
the UTC definition of 2AM depends on the actual location. multiple time zones, the UTC definition of 2AM depends on the actual
location.
This document defines two alternatives for localized scheduling: We define two alternatives for localized scheduling:
o Regional schedule: When used in conjunction with the Location o Regional schedule: When used in conjunction with the Location
Policy defined in Section 4.1, the uCDN can trigger separate Policy defined in Section 4.1, the uCDN can trigger separate
commands for different geographical regions, for each region using commands for different geographical regions, for each region using
a different schedule. This allows the uCDN to control the a different schedule. This allows the uCDN to control the
execution time per region. execution time per region.
o Local Time schedule: We introduce a "local time" version for o Local Time schedule: We introduce a "local time" version for
Internet timestamps that follows the notation for local time as Internet timestamps that follows the notation for local time as
defined in Section 4.2.2 of [ISO8601]. When local time is used, defined in Section 4.2.2 of [ISO8601]. When local time is used,
skipping to change at page 30, line 4 skipping to change at page 30, line 7
trigger at the defined time frame, interpreted as the the local trigger at the defined time frame, interpreted as the the local
time per location. time per location.
Type: LocalTimeWindow object as defined in Section 4.2.2. Type: LocalTimeWindow object as defined in Section 4.2.2.
Mandatory-to-Specify: No, but exactly one of "unix-time- Mandatory-to-Specify: No, but exactly one of "unix-time-
window", "utc-window" or "local-time-window" MUST be present. window", "utc-window" or "local-time-window" MUST be present.
If a time policy object is not listed within the trigger command, the If a time policy object is not listed within the trigger command, the
default behavior is to execute the trigger in a time frame most default behavior is to execute the trigger in a time frame most
suitable to the dCDN taking under consideration other constrains and/ suitable to the dCDN taking under consideration other constrains and
or obligations. / or obligations.
Example of a generic trigger extension object containing a time Example of a generic trigger extension object containing a time
policy object that schedules the trigger execution to a window policy object that schedules the trigger execution to a window
between 09:00 01/01/2000 UTC and 17:00 01/01/2000 UTC, using the between 09:00 01/01/2000 UTC and 17:00 01/01/2000 UTC, using the
"unix-time-window" property: "unix-time-window" property:
{ {
"generic-trigger-extension-type": "CIT.TimePolicy", "generic-trigger-extension-type": "CIT.TimePolicy",
"generic-trigger-extension-value": "generic-trigger-extension-value":
{ {
skipping to change at page 30, line 41 skipping to change at page 30, line 44
Property: start Property: start
Description: The start time of the window. Description: The start time of the window.
Type: Internet date and time as defined in [RFC3339]. Type: Internet date and time as defined in [RFC3339].
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: end Property: end
Description: The end-time of the window. Description: The end time of the window.
Type: Internet date and time as defined in [RFC3339]. Type: Internet date and time as defined in [RFC3339].
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Example UTCWindow object that describes a time window from 02:30 Example UTCWindow object that describes a time window from 02:30
01/01/2000 UTC to 04:30 01/01/2000 UTC: 01/01/2000 UTC to 04:30 01/01/2000 UTC:
{ {
"start": 2000-01-01T02:30:00.00Z, "start": 2000-01-01T02:30:00.00Z,
skipping to change at page 31, line 29 skipping to change at page 31, line 29
A LocalTimeWindow object describes a time range in local time. The A LocalTimeWindow object describes a time range in local time. The
reader of this object MUST interpret it as "the local time at the reader of this object MUST interpret it as "the local time at the
location of execution". For example, if the time window states 2AM location of execution". For example, if the time window states 2AM
to 4AM local time then a dCDN that has presence in both London (UTC) to 4AM local time then a dCDN that has presence in both London (UTC)
and New York (UTC-05:00) will execute the trigger at 2AM-4AM UTC in and New York (UTC-05:00) will execute the trigger at 2AM-4AM UTC in
London and at 2AM-4AM UTC-05:00 in New York. London and at 2AM-4AM UTC-05:00 in New York.
Property: start Property: start
Description: The start-time of the window. Description: The start time of the window.
Type: JSON string formatted as DateLocalTime as defined in Type: JSON string formatted as DateLocalTime as defined in
Section 4.2.3. Section 4.2.3.
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: end Property: end
Description: The end time of the window. Description: The end time of the window.
skipping to change at page 39, line 47 skipping to change at page 39, line 47
document. document.
8. Acknowledgments 8. Acknowledgments
TBD TBD
9. Contributors 9. Contributors
The authors would like to thank all members of the "Streaming Video The authors would like to thank all members of the "Streaming Video
Alliance" (SVA) Open Caching Working Group for their contribution in Alliance" (SVA) Open Caching Working Group for their contribution in
support of this document. Authors also thank Kevin J. Ma for his support of this document.
reviews and comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
skipping to change at page 40, line 49 skipping to change at page 40, line 49
R., and K. Ma, "Content Delivery Network Interconnection R., and K. Ma, "Content Delivery Network Interconnection
(CDNI) Request Routing: Footprint and Capabilities (CDNI) Request Routing: Footprint and Capabilities
Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016,
<https://www.rfc-editor.org/info/rfc8008>. <https://www.rfc-editor.org/info/rfc8008>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
10.2. Informative References 10.2. Informative References
[ISO8601] ISO, "Data elements and interchange formats -- Information [ISO8601] ISO, "Data elements and interchange formats -- Information
interchange -- Representation of dates and times", interchange -- Representation of dates and times",
ISO 8601:2004, Edition 3, 12 2004, ISO 8601:2004, Edition 3, 12 2004,
 End of changes. 21 change blocks. 
66 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/