<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
     category="std" consensus="true"
     docName="draft-ietf-cdni-request-routing-extensions-08" ipr="trust200902"> number="8804"
     ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true"
     tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="CDNI Request Routing Extensions">CDNI Extensions">Content Delivery
    Network Interconnection (CDNI) Request Routing Extensions</title>

    <seriesInfo name="RFC" value="8804"/>
    <author fullname="Ori Finkelman" initials="O." surname="Finkelman">
      <organization>Qwilt</organization>
      <address>
        <postal>
          <street>6, Ha'harash</street>
          <city>Hod HaSharon</city>

          <region></region>
          <region/>
          <code>4524079</code>
          <country>Israel</country>
        </postal>

       <phone></phone>
        <phone/>
        <email>ori.finkelman.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Sanjay Mishra" initials="S." surname="Mishra">
      <organization>Verizon</organization>
      <address>
        <postal>
          <street>13100 Columbia Pike</street>
          <city>Silver Spring</city>
          <region>MD</region>
          <code>20904</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>

        <phone></phone>
        <phone/>
        <email>sanjay.mishra@verizon.com</email>
      </address>
    </author>

    <date/>
    <date year="2020" month="September"/>

    <abstract>
      <t>Open Caching architecture is a use case of Content Delivery Networks Network
      Interconnection (CDNI) in which the commercial Content Delivery Network
      (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the
      downstream CDN (dCDN). The extensions specified in this  This document defines extensions to the CDNI
      Metadata Interface (MI) and the Footprint and &amp; Capabilities Interface (FCI)
      Advertisement interface (FCI). These extensions are derived from
      requirements raised by Open Caching but are also applicable to CDNI use
      cases in general.</t> general.
</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The <xref target="SVA">Streaming Streaming Video Alliance</xref> Alliance <xref target="SVA" format="default"/> is
      a global association that works to solve
      streaming video challenges in an effort to improve end-user experience
      and adoption. The <xref target="OCWG">Open Open Caching Working Group</xref> Group <xref target="OCWG"
      format="default"/> of the <xref target="SVA">Streaming Streaming Video Alliance</xref> Alliance <xref target="SVA"
      format="default"/> is focused on the
      delegation of video delivery requests from commercial CDNs to a caching
      layer at the Internet
         Service Provider's (ISP) ISP's network. Open Caching
      architecture is a specific use case of CDNI where the commercial CDN is
      the upstream CDN (uCDN) and the ISP caching layer is the downstream CDN
      (dCDN). The <xref target="OC-RR">Open Open Caching Request Routing Specification</xref> Functional Specification <xref
      target="OC-RR" format="default"/> defines the Request Routing process
      and the
      interfaces that are required for its provisioning.

This document defines and registers the CDNI metadata object <xref target="RFC8006"/>
target="RFC8006" format="default"/> and the CDNI Footprint and Capabilities
object <xref target="RFC8008"/> target="RFC8008" format="default"/> that are required for Open
Caching Request Routing. For Routing:</t>

      <ul spacing="normal">
        <li>Redirect Target Capability (for dCDN advertising redirect target
	address)</li>
        <li>Fallback Target Metadata (for uCDN configuring fallback target
	address)</li>
      </ul>
      <t>This document also registers CDNI Payload Types <xref
      target="RFC7736" format="default"/> for these defined objects.
      </t>

<t>For consistency with other CDNI documents documents, this
document follows the CDNI convention of uCDN (upstream CDN) and dCDN
(downstream CDN) to represent the commercial CDN and ISP caching
         layer layer,
respectively.</t>

      <t>This document also registers CDNI Payload Types <xref target="RFC7736"/> for the defined objects:
          <list style="symbols">
            <t>Redirect Target Capability (for dCDN advertising redirect target address)</t>
            <t>Fallback Target Metadata (for uCDN configuring fallback target address)</t>
          </list>
      </t>

      <section anchor="terminology" title="Terminology"> numbered="true" toc="default">
        <name>Terminology</name>
        <t>The following terms are used throughout this document:
          <list style="symbols">
            <t>FQDN - Fully document:</t>
        <dl newline="false" spacing="normal" indent="8">
          <dt>FQDN</dt>
	  <dd>Fully Qualified Domain Name</t>
            <t>CDN - Content Name</dd>
          <dt>CDN</dt>
	  <dd>Content Delivery Network</t>
          </list>
        </t> Network</dd>
        </dl>
        <t>Additionally, this document reuses the terminology defined in <xref target="RFC6707"/>,
	target="RFC6707" format="default"/>, <xref target="RFC7336"/>, target="RFC7336"
	format="default"/>, <xref target="RFC8006"/>, target="RFC8006" format="default"/>, <xref target="RFC8007"/>,
	target="RFC8007" format="default"/>, and <xref target="RFC8008"/>. target="RFC8008"
	format="default"/>. Specifically, we use the following CDNI acronyms:
          <list style="symbols">
            <t>FCI - Footprint and Capability Interface
	acronyms:</t>
        <dl newline="false" spacing="normal" indent="8">
          <dt>FCI</dt>
	  <dd>Footprint &amp; Capabilities Advertisement interface (see <xref target="RFC8008"/>)</t>
            <t>MI - Metadata
	  target="RFC8008" format="default"/>)</dd>
          <dt>MI</dt>
	  <dd>Metadata Interface (see <xref target="RFC8006"/>)</t>
            <t>uCDN, dCDN - Upstream target="RFC8006"
	  format="default"/>)</dd>
          <dt>uCDN</dt>
	  <dd>Upstream CDN and Downstream (see
	  <xref target="RFC7336" format="default"/>)</dd>
          <dt>dCDN</dt>
	  <dd>Downstream CDN respectively (see
	  <xref target="RFC7336"/>)</t>
            <t>RT - Redirection target="RFC7336" format="default"/>)</dd>

          <dt>RT</dt>
	  <dd>Redirection Target. Endpoint for redirection from uCDN to dCDN.</t>
            <t>RR - Request
	  dCDN.</dd>
          <dt>RR</dt>
	  <dd>Request Router. An element responsible for routing user
	  requests, typically using HTTP redirect or DNS CNAME, depending on
	  the use case.</t>
          </list>
        </t> case.</dd>
        </dl>

      </section>
      <section title="Requirements Language"> numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
         "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	"<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
	are to be interpreted as described in BCP 14 BCP&nbsp;14 <xref
	target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
	appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="redirect-target-capability" title="Redirect numbered="true" toc="default">
      <name>Redirect Target Capability"> Capability</name>
      <t>Iterative request redirection CDNI Request Redirection is defined in Section 1.1 of <xref target="RFC7336"/>
      target="RFC7336" sectionFormat="of" section="1.1"/> and elaborated by examples in
      Sections 3.2 <xref target="RFC7336" section="3.2"
      sectionFormat="bare"/> and 3.4 <xref target="RFC7336" section="3.4"
      sectionFormat="bare"/> of <xref target="RFC7336"/>. target="RFC7336" format="default"/>.  A
      Redirection Target (RT) is defined in
         Section 2 of <xref target="RFC7975"/>
      target="RFC7975" sectionFormat="of" section ="2"/> for Recursive Request Redirection as:
      </t>
      <t><list style="empty">
        <t>
           "The
      as:</t>
      <blockquote>The endpoint to which the User Agent is redirected.  In
      CDNI, a an RT may point to a number of different components, some examples
      include a surrogate in the same CDN as the request router, a request
      router in a dCDN, or a surrogate in a dCDN".
        </t>
      </list></t>
      <t>
         In dCDN.</blockquote>
      <t>In this document document, we adopt the same definition of the RT for the
      Iterative Request Redirect use case. This use case requires the
      provisioning of the RT address to be used by the uCDN in order to
      redirect to the dCDN. RT addresses can vary between different footprints, for
      footprints (for example, between different regions, regions), and they may also
      change over time, for example time (for example, as a result of network problems. problems). Given
      this variable and dynamic nature of the redirect target address, it may
      not be suitable to advertise it during bootstrap. A more dynamic and footprint oriented
      footprint-oriented interface is required. Section 4.3 of <xref target="RFC7336"/>
      target="RFC7336" sectionFormat="of" section="4.3"/> suggests that it
      could be one of the
      roles of the FCI <xref target="RFC8008"/>. target="RFC8008" format="default"/>. Following
      this suggestion, we have
         therefore, therefore chosen to use the CDNI Footprint and &amp;
      Capabilities Advertisement interface for redirect target address advertisement.
      </t> advertisement.</t>
      <t>Use cases<list style="symbols">
         <t>Footprint: cases:</t>
      <ul spacing="normal">
        <li>Footprint: The dCDN may want to have a different target per
	footprint. Note that a dCDN may spread across multiple
	geographies. This makes it easier to route client requests to a nearby
	request router. Though this can be achieved using a single canonical
	name and "Geo DNS", such that in different geographies the same
	hostname is resolved to different IP address, that approach has
	limitations; for example example, a client may be using a third party third-party DNS
	resolver, making it impossible for the redirector to detect where the
	client is located, or Geo DNS granularity may be too rough for the
	requirement of the application.</t>

         <t>Scaling: application.</li>
        <li>Scaling: The dCDN may choose to scale its request routing Request Routing service
	by deploying more request routers in new locations and advertise them
	via an updatable interface like the FCI.</t>

      </list></t> FCI.</li>
      </ul>
      <t>The Redirect Target capability object is used to indicate the target
      address the uCDN should use in order to redirect a client to the dCDN. A
      target may be attached to a specific uCDN host, attached to a list of
      uCDN hosts, or used globally for all the hosts of the uCDN.
      </t>
      <t>
         When uCDN.</t>
      <t>When a dCDN is attaching the redirect target to a specific uCDN host
      or a list of uCDN hosts, the dCDN MUST <bcp14>MUST</bcp14> advertise the
      hosts within the Redirect Target capability object as
      "redirecting-hosts". In this case, the uCDN can redirect to that dCDN
      address, only if the User Agent request was to one of these uCDN hosts.
      </t>

      <t>
         If
      hosts.</t>
      <t>If the redirect target Redirect Target capability object does not contain a target or
      the target is empty, the uCDN MUST <bcp14>MUST</bcp14> interpret it as "no
      target available for these uCDN hosts for the specified footprint". In
      case such a target was already advertised in a previous FCI object, the
      uCDN MUST <bcp14>MUST</bcp14> interpret it as an update that deletes the
      previous redirect target.
       </t> target.</t>
      <section title="DNS numbered="true" toc="default">
        <name>DNS Redirect Target">
        <t>
            A Target</name>
        <t>A redirect target for DNS redirection is a an FQDN used as an alias in
	a CNAME record response (see <xref target="RFC1034"/>) target="RFC1034"
	format="default"/>) of the uCDN DNS router.
	Note that DNS routers make
	routing decisions based on either the DNS resolver's IP address or the
	client IP subnet when EDNS0 client-subnet (ECS) is used (see <xref target="RFC7871"/>).
	target="RFC7871" format="default"/>). The dCDN may choose to advertise
	redirect targets and footprints to cover both cases, such that the
	uCDN resolution would route the DNS query to a different dCDN CNAMEs
	according to client subnet or dCDN resolver IP address. This method
	further allows the dCDN DNS to optimize the resolution by localizing
	the target CNAMEs. A uCDN implementation SHOULD <bcp14>SHOULD</bcp14> prefer
	routing based on client IP subnet when the ECS option is present. A dCDN
	implementation using the ECS option MUST <bcp14>MUST</bcp14> be aware of
	the privacy drawbacks listed in Section 2 of <xref target="RFC7871"/> target="RFC7871"
	sectionFormat="of" section="2"/> and SHOULD <bcp14>SHOULD</bcp14> follow the
	guidelines provided in Section 11.1 of <xref target="RFC7871"/>.
        </t> target="RFC7871" sectionFormat="of"
	section="11.1"/>.</t>
      </section>
      <section title="HTTP numbered="true" toc="default">
        <name>HTTP Redirect Target">
        <t>
            A Target</name>
        <t>A redirect target for HTTP redirection is the URI to be used as the
	value for the Location header of a an HTTP redirect 3xx response,
	typically a 302 (Found) (see Section 7.1.2 of <xref target="RFC7231"/> target="RFC7231"
	sectionFormat="of" section="7.1.2"/> and section 6.4 of <xref target="RFC7231"/>). target="RFC7231"
	sectionFormat="of" section="6.4"/>).
        </t>
      </section>
      <section anchor="redirect-target-capability-properties" title="Properties numbered="true" toc="default">
        <name>Properties of Redirect Target Capability Object"> Object</name>
        <t>The Redirect Target capability object consists of the following
	properties:</t>
         <t><list style="empty">
            <t>Property: redirecting-hosts<list style="empty">

               <t>Description: One

<dl newline="false" spacing="normal">

       <dt>Property:</dt><dd><t>redirecting-hosts</t>

          <dl newline="false" spacing="normal">

              <dt>Description:</dt><dd>One or more uCDN hosts to which this
              redirect target is attached. A redirecting host SHOULD
              <bcp14>SHOULD</bcp14> be a host that was published in a
              HostMatch object by the uCDN as defined in Section 4.1.2 of <xref target="RFC8006"/>.</t>

               <t>Type: A
              target="RFC8006" sectionFormat="of" section="4.1.2"/>.</dd>

              <dt>Type:</dt><dd>A list of Endpoint objects (see Section 4.3.3 of <xref target="RFC8006"/>)</t>

               <t>Mandatory-to-Specify: No.
	      target="RFC8006" sectionFormat="of" section="4.3.3"/>)</dd>

              <dt>Mandatory-to-Specify:</dt><dd>No. If not present, absent or empty, the
	      redirect target applies to all hosts of the redirecting uCDN.</t>
            </list></t>
            <t>Property: dns-target<list style="empty">

               <t>Description: Target
	      uCDN.</dd>
          </dl></dd>

            <dt>Property:</dt><dd><t>dns-target</t>

          <dl newline="true" spacing="normal">

              <dt>Description:</dt><dd>Target CNAME record for DNS redirection.</t>

               <t>Type: DnsTarget
              redirection.</dd>

              <dt>Type:</dt><dd>DnsTarget object (see <xref target="dns-target"/>)</t>

               <t>Mandatory-to-Specify: No. target="dns-target"
	      format="default"/>)</dd>

              <dt>Mandatory-to-Specify:</dt><dd>No. If the dns-target is not present
	      absent or empty empty, the uCDN MUST <bcp14>MUST</bcp14> interpret it as
              "no dns-target available".</t>
            </list></t>
            <t>Property: http-target<list style="empty">

               <t>Description: Target available".</dd>

          </dl></dd>

            <dt>Property:</dt><dd><t>http-target</t>

          <dl newline="true" spacing="normal">

              <dt>Description:</dt><dd>Target URI for a an HTTP redirect.</t>

               <t>Type: HttpTarget redirect.</dd>
              <dt>Type:</dt><dd>HttpTarget object (see <xref target="http-target"/>)</t>

               <t>Mandatory-to-Specify: No. target="http-target"
	      format="default"/>)</dd>
              <dt>Mandatory-to-Specify:</dt><dd>No. If the http-target is not present
              absent or empty empty, the uCDN MUST <bcp14>MUST</bcp14> interpret it as
              "no http-target available".</t>
            </list></t>

         </list></t> available".</dd>
          </dl></dd>

</dl>

        <t>The following is an example of a Redirect Target capability object
	serialization that advertises a dCDN target address that is attached
	to a specific list of uCDN "redirecting-hosts". A uCDN host that is
	included in that list can redirect to the advertised dCDN redirect
	target. The capabilities object is serialized as a JSON object as
	defined in Section 5.1
            of <xref target="RFC8008"/>
         </t>

         <figure>
           <artwork><![CDATA[ target="RFC8008" sectionFormat="of"
	section="5.1"/>.</t>
<sourcecode name="" type="json"><![CDATA[
{
  "capabilities": [
    {
      "capability-type": "FCI.RedirectTarget",
      "capability-value": {
          "redirecting-hosts": [
             "a.service123.ucdn.example.com",
             "b.service123.ucdn.example.com"
          ],
          "dns-target": {
             "host": "service123.ucdn.dcdn.example.com"
          },
          "http-target": {
              "host": "us-east1.dcdn.example.com",
              "path-prefix": "/cache/1/",
              "include-redirecting-host": true
          }
      },
      "footprints": [
          <Footprint objects>
      ]
    }
  ]
}
         ]]></artwork>
         </figure>
]]></sourcecode>

      </section>
      <section anchor="dns-target" title="DnsTarget Object"> numbered="true" toc="default">
        <name>DnsTarget Object</name>
        <t>The DnsTarget object gives the target address for the DNS response
	to delegate from the uCDN to the dCDN.</t>

         <t><list style="empty">
            <t>Property: host<list style="empty">

               <t>Description: The

<dl newline="false" spacing="normal">

            <dt>Property:</dt><dd><t>host</t>

   <dl newline="false" spacing="normal">
              <dt>Description:</dt><dd>The host property is a hostname or an IP
	      address, without a port number.</t>

               <t>Type: Endpoint number.</dd>
              <dt>Type:</dt><dd>Endpoint object as defined in Section 4.3.3 of <xref target="RFC8006"/>
              target="RFC8006" sectionFormat="of" section="4.3.3"/>, with the
              limitation that it SHOULD NOT <bcp14>SHOULD NOT</bcp14> include a port
              number and, in case a port number is present, the uCDN MUST
              <bcp14>MUST</bcp14> ignore it.</t>

               <t>Mandatory-to-Specify: Yes.</t>
            </list></t>
         </list></t> it.</dd>
              <dt>Mandatory-to-Specify:</dt><dd>Yes.</dd>
   </dl></dd>
</dl>

        <section title="DNS Target Example"> numbered="true" toc="default">
          <name>DnsTarget Example</name>
          <t>The following is an example of the DnsTarget object:</t>
            <figure>
                <artwork><![CDATA[
<sourcecode name="" type="json"><![CDATA[
{
   "host": "service123.ucdn.dcdn.example.com"
}
            ]]></artwork>
            </figure>
]]></sourcecode>
          <t>The following is an example of a DNS query for uCDN address
	  "a.service123.ucdn.example.com" and the corresponding CNAME
	  redirection response:</t>
            <figure>
                <artwork><![CDATA[
<artwork name="" type="" align="left" alt=""><![CDATA[
Query:
a.service123.ucdn.example.com:
type A, class IN

Response:
NAME: a.service123.ucdn.example.com, TYPE: CNAME, CLASS: IN,
TTL: 120, RDATA: service123.ucdn.dcdn.example.com
]]></artwork>
            </figure>
        </section>
      </section>
      <section anchor="http-target" title="HttpTarget Object"> numbered="true" toc="default">
        <name>HttpTarget Object</name>
        <t>The HttpTarget object gives the necessary information to construct
	the target Location URI for HTTP redirection.</t>

         <t><list style="empty">
            <t>Property: host<list style="empty">

               <t>Description: Hostname

<dl newline="false" spacing="normal">

       <dt>Property:</dt><dd><t>host</t>
            <dl newline="false" spacing="normal">
              <dt>Description:</dt><dd>Hostname or IP address and an optional
              port, i.e., the host and port of the authority component of the
              URI as described in Section 3.2 of <xref target="RFC3986"/>.</t>

               <t>Type: Endpoint target="RFC3986" sectionFormat="of"
              section="3.2"/>.</dd>
              <dt>Type:</dt><dd>Endpoint object as defined in Section 4.3.3 of <xref target="RFC8006"/>.</t>

               <t>Mandatory-to-Specify: Yes.</t>
            </list></t>
            <t>Property: scheme<list style="empty">

               <t>Description: A
	      target="RFC8006" sectionFormat="of" section="4.3.3"/>.</dd>
              <dt>Mandatory-to-Specify:</dt><dd>Yes.</dd>
	    </dl></dd>

        <dt>Property:</dt><dd><t>scheme</t>
            <dl newline="false" spacing="normal">
              <dt>Description:</dt><dd>A URI scheme to be used in the redirect
	      response location construction. When present, the uCDN MUST
	      <bcp14>MUST</bcp14> use the provided scheme in for HTTP
	      redirection to the dCDN.</t>

               <t>Type: A dCDN.</dd>
              <dt>Type:</dt><dd>A URI scheme as defined in Section 3.1 of <xref target="RFC3986"/> target="RFC3986"
	      sectionFormat="of" section="3.1"/>, represented as a JSON
	      string. The scheme MUST <bcp14>MUST</bcp14> be either "http" or "https".</t>

               <t>Mandatory-to-Specify: No.
	      "https".</dd>
              <dt>Mandatory-to-Specify:</dt><dd>No. If this property is absent or empty
	      empty, the uCDN request router MUST <bcp14>MUST</bcp14> use the same
	      scheme as was used in the original request before redirection.</t>
            </list></t>
            <t>Property: path-prefix<list style="empty">

               <t>Description: A
	      redirection.</dd>
            </dl></dd>

        <dt>Property:</dt><dd><t>path-prefix</t>
            <dl newline="false" spacing="normal">
              <dt>Description:</dt><dd>A path prefix for the HTTP redirect
              Location header. The original path is appended after this prefix.</t>

               <t>Type: A
              prefix.</dd>
              <dt>Type:</dt><dd>A prefix of a path-absolute as defined in Section 3.3 of
              <xref target="RFC3986"/>. target="RFC3986" sectionFormat="of" section="3.3"/>. The
              prefix MUST <bcp14>MUST</bcp14> end with a trailing slash, slash to indicate
              the end of the last path segment in the prefix.</t>

               <t>Mandatory-to-Specify: No. prefix.</dd>
              <dt>Mandatory-to-Specify:</dt><dd>No. If this property is absent
              or empty, the uCDN MUST NOT <bcp14>MUST NOT</bcp14> prepend a path prefix path-prefix
              to the original content path, i.e., the original path MUST
              <bcp14>MUST</bcp14> appear in the location Location URI right after the
              authority component.</t>
            </list></t>

            <t>Property: include-redirecting-host<list style="empty">

               <t>Description: A component.</dd>
       </dl></dd>

        <dt>Property:</dt><dd><t>include-redirecting-host</t>
            <dl newline="false" spacing="normal">
              <dt>Description:</dt><dd>A flag indicating whether or not to
              include the redirecting host as the first path segment after the
              path-prefix. If set to true and a "path-prefix" is used, the
              uCDN redirecting host MUST <bcp14>MUST</bcp14> be added as a separate
              path segment after the path-prefix and before the original URL
              path. If set to true and there is no path-prefix, the uCDN
              redirecting host MUST <bcp14>MUST</bcp14> be prepended as the first
              path segment in the redirect URL.</t>

               <t>Type: Boolean.</t>

               <t>Mandatory-to-Specify: No. URL.</dd>
              <dt>Type:</dt><dd>Boolean.</dd>
              <dt>Mandatory-to-Specify:</dt><dd>No. Default value is False.</t>
            </list></t>
         </list></t> False.</dd>
	 </dl></dd>

</dl>

        <section title="HTTP Target Example">
            <t>Example numbered="true" toc="default">
          <name>HttpTarget Example</name>
          <t>The following is an example of the HttpTarget object with a "scheme", a "path-prefix",
	  and "include-redirecting-host" properties:</t>

            <figure>
                <artwork><![CDATA[
<sourcecode name="" type="json"><![CDATA[
{
   "host": "us-east1.dcdn.example.com",
   "scheme": "https",
   "path-prefix": "/cache/1/",
   "include-redirecting-host": true
}
            ]]></artwork>
            </figure>
                <t>Example
]]></sourcecode>
          <t>The following is an example of a an HTTP request for content at uCDN host
	  "a.service123.ucdn.example.com" and the corresponding HTTP response
	  with a Location header, used for redirecting the client to the dCDN,
	  constructed according to the HttpTarget object from the above
	  example:</t>
            <figure>
                <artwork><![CDATA[
<artwork name="" type="" align="left" alt=""><![CDATA[
Request:
GET /vod/1/movie.mp4 HTTP/1.1
Host: a.service123.ucdn.example.com

Response:
HTTP/1.1 302 Found
Location: https://us-east1.dcdn.example.com/cache/1/
a.service123.ucdn.example.com/vod/1/movie.mp4
]]></artwork>
            </figure>
        </section>
      </section>
      <section anchor="redirect-target-usage-example" title="Usage Example">
         <t>
           Before numbered="true" toc="default">
        <name>Usage Example</name>
        <t>Before requests can be routed from the uCDN to the dCDN dCDN, the CDNs
        must exchange service configurations between them. Using the MI, the
        uCDN advertises out-of-band its hosts to the dCDN, dCDN; each host is
        designated by a hostname and has its own specific metadata (see Section 4.1.2 of <xref target="RFC8006"/>.
           The dCDN, using
        target="RFC8006" sectionFormat="of" section="4.1.2"/>). Using the FCI, advertises, also out-of-band,
        the dCDN advertises (also out-of-band) the redirect target address object
        defined in <xref target="redirect-target-capability-properties"/> target="redirect-target-capability-properties"
        format="default"/> for the relevant uCDN hosts. The following is a
        generalized example of the message flow between an upstream CDN a uCDN and a downstream dCDN. For
        simplicity, we focus on the sequence of messages between the uCDN and
        dCDN and not on how they are passed.
         </t>

         <figure>
           <artwork><![CDATA[ passed.</t>

<figure anchor="redirect">
<name>Redirect Target Address Advertisement</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
  dCDN                                                    uCDN
    +                                                       +
    |                                                       |
(1) | MI:  host: s123.ucdn.example.com                      |
    |      host-metadata: < metadata >                      |
    <-------------------------------------------------------+
    |                                                       |
(2) | FCI:  capability-type: FCI.RedirectTarget             |
    |       redirecting-hosts: s123.ucdn.example.com        |
    |       target host: us-east1.dcdn.example.com          |
    +------------------------------------------------------->
    |                                                       |
    |                                                       |
    +                                                       +

    Figure 1: Redirect target address advertisement
]]></artwork>
</figure>
         <t><list style="numbers">
           <t>
             The

<t>Explanation:
</t>
        <ol spacing="normal" type="(%d)">
          <li>The uCDN advertises a host (s123.ucdn.example.com) with the host metadata.
           </t>
           <t>
             The
	  metadata.</li>
          <li>The dCDN advertises its FCI objects to the uCDN uCDN, including a FCI.RedirectTarget
          Redirect Target capability object that contains the redirect target
          address (us-east1.dcdn.example.com) specified for that uCDN host.
           </t>
         </list></t>

         <t>
           Once
          host.</li>
        </ol>
        <t>Once the redirect target has been set, the uCDN can start
	redirecting user requests to the dCDN. The following is a generic
	sequence of redirection using the host and redirect target that were
	advertised in Figure 1 above.
         </t>

         <figure>
           <artwork><![CDATA[ <xref target="redirect"/>.</t>
	<figure anchor="generic">
	  <name>Generic Request Redirection Sequence</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
End User                  dCDN                   uCDN RR
    +                       +                       +
    |                       |                       |
(1) | Request sent s123.ucdn.example.com            |
    +-----------------------+----------------------->
    |                       |                       |
(2) | Redirect to us-east1.dcdn.example.com         |
    <-----------------------+-----------------------+
    |                       |                       |
(3) | Request us-east1.dcdn.example.com             |
    +----------------------->                       |
    |                       |                       |
(4) | Response              |                       |
    <-----------------------+                       |
    |                       |                       |
    +                       +                       +

    Figure 2: Generic requests redirection sequence
]]></artwork>
	</figure>
         <t><list style="numbers">
           <t>
             The

<t>Explanation:</t>
        <ol spacing="normal" type="(%d)">
          <li>The End User sends a request (DNS or HTTP) to the uCDN Request
	  Router (RR).
           </t>
           <t>
             Using (RR).</li>
          <li>Using the previously advertised Redirect Target, the uCDN
	  redirects the request to the
             dCDN.
           </t>
           <t>
             The dCDN.</li>
          <li>The End User sends a request to the dCDN.
           </t>
           <t>
             The dCDN.</li>
          <li>The dCDN either sends a response or reroutes it, for example, to
	  a dCDN surrogate.
           </t>
         </list></t> surrogate.</li>
        </ol>
      </section>
    </section>
    <section anchor="fallback-target-metadata" title="Fallback numbered="true" toc="default">
      <name>Fallback Target Address Metadata"> Server Address</name>
      <t>Open Caching requires that the uCDN provides a fallback target server
      to the
         dCDN, dCDN to be used in cases where the dCDN cannot properly handle
      the request. To avoid redirect loops, the fallback target server's
      address at the uCDN MUST <bcp14>MUST</bcp14> be different from the original
      uCDN address from which the client was redirected to the dCDN. The uCDN MUST
      <bcp14>MUST</bcp14> avoid further redirection when receiving the client
      request at the fallback target. The fallback target Fallback Target is defined as a
      generic metadata object (see Section 3.2 of <xref target="RFC8006"/>)</t> target="RFC8006"
      sectionFormat="of" section="3.2"/>).</t>
      <t>Use cases<list style="symbols">
         <t>Failover: cases:</t>
      <ul spacing="normal">
        <li>Failover: A dCDN request router receives a request but has no
	caches to which it can route the request. This can happen in the case
	of failures or temporary network overload.</t>

         <t>No overload.</li>
        <li>No coverage: A dCDN request router receives a request from a
	client located in an area inside the footprint but not covered by the
	dCDN caches or outside the dCDN  footprint coverage. In such cases,
	the router may choose to redirect the request back to the uCDN
	fallback address.</t>

         <t>Error: address.</li>
        <li>Error: A cache may receive a request that it cannot properly
	serve, for example, some of the metadata objects for that service were
	not properly acquired. In this case, the cache's "default action" may
	be to "redirect back to uCDN".</t>
      </list></t> uCDN".</li>
      </ul>
      <t>The Fallback target Target metadata object is used to indicate the target
      address the dCDN should redirect a client to when falling back to the
      uCDN. Fallback The fallback target address is represented as an endpoint Endpoint object as
      defined in Section 4.3.3 of <xref target="RFC8006"/>.</t> target="RFC8006" sectionFormat="of"
      section="4.3.3"/>.</t>
      <t>In DNS redirection redirection, a CNAME record is used as the fallback target
      address.</t>
      <t>In HTTP redirection redirection, a hostname is used as the fallback target
      address.</t>
      <t>When using HTTP redirect to route a client request back to the uCDN,
      it is the dCDN's responsibility to use the original URL path as the
      client would have used for the original uCDN request, stripping, if
      needed, the dCDN path-prefix and/or the uCDN hostname from the redirect
      URL that may have been used to request the content from the dCDN.</t>
      <section anchor="fallback-target-metadata-properties" title="Properties numbered="true"
	       toc="default">
        <name>Properties of Fallback Target Address Generic Metadata Object"> Object</name>

        <t>The MI.FallbackTarget Metadata generic metadata object consists of the following single property:</t>
         <t><list style="empty">
            <t>Property: host<list style="empty">

               <t>Description: Target
	two properties:</t>

<dl newline="false" spacing="normal">

      <dt>Property:</dt><dd><t>host</t>
        <dl newline="false" spacing="normal">
              <dt>Description:</dt><dd>Target address to which the dCDN can
              redirect the client.</t>

               <t>Type: Endpoint client.</dd>
              <dt>Type:</dt><dd>Endpoint object as defined in Section 4.3.3 of <xref target="RFC8006"/>
              target="RFC8006" sectionFormat="of" section="4.3.3"/>, with the
              limitation that in case of DNS delegation delegation, it SHOULD NOT <bcp14>SHOULD
              NOT</bcp14> include a port number and, number, and in case a port number is
              present, the dCDN MUST <bcp14>MUST</bcp14> ignore it.</t>

               <t>Mandatory-to-Specify: Yes.</t>
            </list></t>
            <t>Property: scheme<list style="empty">

               <t>Description: A it.</dd>
              <dt>Mandatory-to-Specify:</dt><dd>Yes.</dd>

	</dl></dd>

        <dt>Property:</dt><dd><t>scheme</t>
        <dl newline="false" spacing="normal">
              <dt>Description:</dt><dd>A URI scheme to be used in the redirect
	      response location construction. When present, the dCDN MUST
	      <bcp14>MUST</bcp14> use this scheme in case of HTTP redirection
	      to the uCDN fallback address.</t>

               <t>Type: A address.</dd>
              <dt>Type:</dt><dd>A URI scheme as defined in Section 3.1 of <xref target="RFC3986"/> target="RFC3986"
	      sectionFormat="of" section="3.1"/>, represented as a JSON
	      string. The scheme MUST <bcp14>MUST</bcp14> be either "http" or "https".</t>

               <t>Mandatory-to-Specify: No.
	      "https".</dd>
              <dt>Mandatory-to-Specify:</dt><dd>No. In case of HTTP redirection to
	      fallback, if this property is absent or empty, the dCDN
	      redirecting entity MUST <bcp14>MUST</bcp14> use the same scheme as in
	      the request received by the dCDN.</t>
            </list></t>
         </list></t>

         <t>Example dCDN.</dd>
            </dl></dd>

</dl>

        <t>The following is an example of a an MI.FallbackTarget Metadata generic
        metadata object that designates the host address the dCDN should use
        as fallback address to redirect back to the uCDN.</t>

         <figure>
            <artwork><![CDATA[ uCDN:</t>
<sourcecode name="" type="json"><![CDATA[
{
    "generic-metadata-type": "MI.FallbackTarget",
    "generic-metadata-value":
    {
        "host": "fallback-a.service123.ucdn.example",
        "scheme": "https"
    }
}
         ]]></artwork>
         </figure>
]]></sourcecode>
      </section>
      <section anchor="fallback-address-usage-example" title="Usage Example">
         <t>
           The numbered="true" toc="default">
        <name>Usage Example</name>
        <t>The uCDN advertises out-of-band the fallback target address to the
	dCDN, so that the dCDN may redirect a request back to the uCDN in case
	the dCDN cannot serve it. Using the MI MI, the uCDN advertises its hosts
	to the dCDN, along with their specific host metadata (see Section 4.1.2 of <xref target="RFC8006"/>.
	target="RFC8006" sectionFormat="of" section="4.1.2"/>). The Fallback
	Target generic metadata object is encapsulated within the
	"host-metadata" property of each host. The following is an example of
	a message flow between an upstream CDN a uCDN and a downstream dCDN.  For
	simplicity, we focus on the sequence of messages between the uCDN and
	dCDN, not on how they are passed.
         </t>

         <figure>
           <artwork><![CDATA[ passed.</t>
	<figure anchor="fallback">
	  <name>Advertisement of Host Metadata with Fallback Target</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
  dCDN                                                    uCDN
    +                                                       +
    |                                                       |
(1) | MI:  host: s123.ucdn.example.com                      |
    |      host-metadata:                                   |
    |          < metadata objects >                         |
    |          < MI.FallbackTarget                          |
    |            host: fallback-a.service123.ucdn.example > |
    |          < metadata objects >                         |
    <-------------------------------------------------------+
    |                                                       |
(2) | FCI:  capability-type: FCI.RedirectTarget             |
    |       redirecting-hosts: s123.ucdn.example.com        |
    |       target host: us-east1.dcdn.example.com          |
    +------------------------------------------------------->
    |                                                       |
    |                                                       |
    +                                                       +

    Figure 3: Advertisement of host metadata with Fallback Target
]]></artwork>
	</figure>
         <t><list style="numbers">
           <t>
             The
<t>Explanation:
</t>
        <ol spacing="normal" type="(%d)">
          <li>The uCDN advertises a host (s123.ucdn.example.com) with the host
          metadata. The host-metadata property contains a an MI.FallbackTarget object.
           </t>
           <t>
             The
          generic metadata object.</li>
          <li>The dCDN advertises its FCI objects to the uCDN uCDN, including a FCI.RedirectTarget
          Redirect Target capability object that contains the redirect target
          address (us-east1.dcdn.example.com) specified for that uCDN host.
          </t>
         </list></t>

         <t>
           The
          host.</li>
        </ol>
        <t>The following is a generic sequence of redirection using the
	configurations that were advertised in
           Figure 3 above. <xref target="fallback"/>. In this case case,
	the dCDN redirects back to the uCDN fallback target address.
         </t>

         <figure>
           <artwork><![CDATA[ address.</t>
<figure anchor="redirection">
<name>Redirection to Fallback Target</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
End User              dCDN            uCDN fallback          uCDN RR
    +                   +                   +                   +
    |                   |                   |                   |
(1) | Request sent s123.ucdn.example.com    |                   |
    +-------------------+-------------------+------------------->
    |                   |                   |                   |
(2) | Redirect to us-east1.dcdn.example.com |                   |
    <-------------------+-------------------+-------------------+
    |                   |                   |                   |
(3) | Request us-east1.dcdn.example.com     |                   |
    +------------------->                   |                   |
    |                   |                   |                   |
(4) | Redirect back to fallback-a.service123.ucdn.example       |
    <-------------------+                   |                   |
    |                   |                   |                   |
(5) | Request fallback-a.service123.ucdn.example                |
    +--------------------------------------->                   |
    |                   |                   |                   |
(6) | Response          |                   |                   |
    <-------------------+-------------------+                   |
    |                   |                   |                   |
    +                   +                   +                   +

    Figure 4: Redirection to Fallback Target
]]></artwork>
</figure>
         <t><list style="numbers">
           <t>
             The

<t>Explanation:
</t>
        <ol spacing="normal" type="(%d)">
          <li>The End User sends a request (DNS or HTTP) to the uCDN Request
	  Router (RR).
           </t>
           <t>
             Using (RR).</li>
          <li>Using the previously advertised Redirect Target, the uCDN
	  redirects the request to the
             dCDN.
           </t>
           <t>
             The dCDN.</li>
          <li>The End User sends a request to the dCDN.
           </t>
           <t>
             The dCDN.</li>
          <li>The dCDN cannot handled handle the request and, therefore, and therefore redirects it
	  back to the uCDN fallback target address.
           </t>
           <t>
             The address.</li>
          <li>The End User sends the request to the uCDN fallback target address.
           </t>
           <t>
             The
	  address.</li>
          <li>The uCDN either sends a response or reroutes it, for example, to
	  a uCDN surrogate.
           </t>
         </list></t> surrogate.</li>
        </ol>
      </section>
      <section title="uCDN addressing considerations"> numbered="true" toc="default">
        <name>uCDN Addressing Considerations</name>
        <t>When advertising fallback addresses to the dCDN dCDN, the uCDN SHOULD
	<bcp14>SHOULD</bcp14> consider the failure use cases that may lead the
	dCDN to route requests to uCDN fallback. In extreme dCDN network
	failures or under denial-of-service (DoS) attacks, requests coming
	from  a large segment or multiple segments of the dCDN may be routed
	back to the uCDN. The uCDN SHOULD <bcp14>SHOULD</bcp14> therefore design its
	fallback addressing scheme and its available resources accordingly. A
	favorable approach would be for the uCDN to use a different fallback
	target address for each uCDN host, enabling it to load balance the
	requests using the same methods as it would for its original
	hosts. See Sections 4.1.2 <xref target="RFC8006" section="4.1.2"
	sectionFormat="bare"/> and 4.1.3 <xref target="RFC8006" section="4.1.3"
	sectionFormat="bare"/> of <xref target="RFC8006"/> target="RFC8006" format="default"/> for
	a detailed description of how to use GenericMetadata objects within
	the HostMatch object advertised in the HostIndex of the uCDN.
        </t> uCDN.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">

      <name>IANA Considerations</name>
      <section anchor="IANA.payload" title="CDNI numbered="true" toc="default">
        <name>CDNI Payload Types">

        <t>This document requests the registration of Types</name>
        <t>IANA has registered the following CDNI
	Payload Types
           under in the IANA "CDNI Payload Types" registry defined in
	<xref target="RFC7736"/>:</t>

        <texttable>
          <ttcol target="RFC7736" format="default"/>:</t>
        <table align="center">
          <thead>
            <tr>
              <th align="left">Payload Type</ttcol>
          <ttcol align="left">Specification</ttcol>

          <c>FCI.RedirectTarget</c>
          <c>RFCthis</c>

          <c>MI.FallbackTarget</c>
          <c>RFCthis</c>

        </texttable>

        <t>[RFC Editor: Please replace RFCthis with the published RFC
        number for this document.]</t> Type</th>
              <th align="left">Specification</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">FCI.RedirectTarget</td>
              <td align="left">RFC 8804</td>
            </tr>
            <tr>
              <td align="left">MI.FallbackTarget</td>
              <td align="left">RFC 8804</td>
            </tr>
          </tbody>
        </table>
        <section anchor="IANA.payload.RedirectTarget" title="CDNI numbered="true" toc="default">
          <name>CDNI FCI RedirectTarget Payload Type">
          <t>Purpose: The Type</name>

<dl newline="false" spacing="normal">
          <dt>Purpose:</dt><dd>The purpose of this payload type is to
             distinguish RedirectTarget FCI objects</t>
          <t>Interface: FCI</t>
          <t>Encoding: see <xref target="redirect-target-capability-properties"/></t> advertisement objects for redirect target.</dd>
          <dt>Interface:</dt><dd>FCI</dd>
          <dt>Encoding:</dt><dd>See <xref
	  target="redirect-target-capability-properties"
	  format="default"/>.</dd>
</dl>

        </section>
        <section anchor="IANA.payload.FallbackTarget" title="CDNI numbered="true" toc="default">
          <name>CDNI MI FallbackTarget Payload Type">
          <t>Purpose: The Type</name>

<dl newline="false" spacing="normal">
          <dt>Purpose:</dt><dd>The purpose of this payload type is to distinguish
	  FallbackTarget MI objects (and any associated capability advertisement)</t>
          <t>Interface: MI/FCI</t>
          <t>Encoding: see <xref target="fallback-target-metadata-properties"/></t>
	  advertisement).</dd>
          <dt>Interface:</dt><dd>MI/FCI</dd>
          <dt>Encoding:</dt><dd>See <xref target="fallback-target-metadata-properties"
	  format="default"/>.</dd>
</dl>
        </section>
      </section>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>

      <t>This specification is in accordance with defines extensions to the CDNI Metadata Interface
      (MI) and the CDNI Request Routing: Footprint and &amp; Capabilities Semantics. Advertisement interface (FCI). As such,
      it is subject to the security and privacy considerations as defined in Section 8 of
      <xref target="RFC8006"/> target="RFC8006" sectionFormat="of" section="8"/> and in Section 7 of
      <xref target="RFC8008"/> respectively.
      </t> target="RFC8008" sectionFormat="of" section="7"/>,
      respectively.</t>
      <section anchor="Privacy" title="Confidentiality numbered="true" toc="default">
        <name>Confidentiality and Privacy"> Privacy</name>
        <t>The Redirect Target FCI capability object potentially reveals information
	about the internal structure of the dCDN network. A third party could
	intercept the FCI transactions and use the information to attack the
	dCDN. The same is also true for the Fallback Target Metadata object generic metadata object, as
	it may reveal information about the internal structure of the uCDN,
	exposing it to external exploits. Implementations of the FCI and MI MUST
	<bcp14>MUST</bcp14> therefore use strong authentication and encryption
	and strictly follow the directions for securing the interface as
	defined for the Metadata Interface in Section 8.3 of <xref target="RFC8006"/>.
          </t>
        </section> target="RFC8006"
	sectionFormat="of" section="8.3"/>.</t>
      </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors thank Nir B.&nbsp;Sopher for reality checks against production use cases, his contribution is significant to this document.
         The authors also thank Ben Niven-Jenkins for his review and feedback and Kevin J.&nbsp;Ma for his guidance throughout the development
         of this document including his regular reviews.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">

      <?rfc include="reference.RFC.1034" ?>

      <?rfc include="reference.RFC.2119" ?>

      <?rfc include="reference.RFC.3986" ?>

      <?rfc include="reference.RFC.6707" ?>

      <?rfc include="reference.RFC.7231" ?>

      <?rfc include="reference.RFC.7336" ?>

      <?rfc include="reference.RFC.7975" ?>

      <?rfc include="reference.RFC.8006" ?>

      <?rfc include="reference.RFC.8007" ?>

      <?rfc include="reference.RFC.8008" ?>

      <?rfc include="reference.RFC.8174" ?>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6707.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7231.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7336.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7975.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8006.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8007.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8008.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>

    <references title="Informative References">

      <?rfc include="reference.RFC.7736" ?>

      <?rfc include="reference.RFC.7871" ?>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7736.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7871.xml"/>

        <reference anchor="SVA" target="https://www.streamingvideoalliance.org">
          <front>
            <title>Streaming Video Alliance Home Page</title> Alliance</title>
            <author/>
          <date/>
          </front>
        </reference>

        <reference anchor="OCWG" target="https://www.streamingvideoalliance.org/technical-groups/open-caching/">
          <front>
            <title>Open Caching Home Page</title>
          <author/>
          <date/> Caching</title>
            <author><organization>Streaming Video Alliance</organization>
            </author>
          </front>
        </reference>

        <reference anchor="OC-RR" target="https://www.streamingvideoalliance.org/books/open-cache-request-routing-functional-specification/">
          <front>
            <title>
              Open Caching - Cache Request Routing Functional Specification
            </title>
            <seriesInfo name="Version" value="1.1"/>
            <author initials="O." surname="Finkelman" fullname="Ori Finkelman" role="editor">
              <organization>Qwilt</organization>
            </author>
            <author initials="J." surname="Hofmann" fullname="Jason Hofmann">
              <organization>Limelight Networks</organization>
            </author>
            <author initials="E." surname="Klein" fullname="Eric Klein">
              <organization>Disney Streaming Services</organization>
            </author>
            <author initials="S." surname="Mishra" fullname="Sanjay Mishra">
              <organization>Verizon</organization>
            </author>
            <author initials="K." surname="Ma" fullname="Kevin J. Ma">
              <organization>Disney Streaming Services</organization>
            </author>
            <author initials="D." surname="Sahar" fullname="Dan Sahar">
              <organization>Qwilt</organization>
            </author>
            <author initials="B." surname="Zurat" fullname="Bill Zurat">
              <organization>Disney Streaming Services</organization>
            </author>
            <date day="4" month="October" year="2019"/> month="November" year="2016"/>
          </front>
        <seriesInfo name="Version" value="1.1"/>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors thank <contact fullname="Nir B. Sopher"/> for reality checks against
      production use cases; his contribution is significant to this
      document. The authors also thank <contact fullname="Ben Niven-Jenkins"/> for his review and
      feedback and <contact fullname="Kevin J. Ma"/> for his guidance throughout the
      development of this document, including his regular reviews.</t>
    </section>

  </back>
</rfc>