<?xml version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

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

  <front>
    <title abbrev="CDNI Capacity Capability Advertisement Extensions">Content Delivery Network Interconnection (CDNI) 
    Capacity Capability Advertisement Extensions</title>
    <seriesInfo name="RFC" value="9808"/>
    <author fullname="Andrew Ryan" initials="A." surname="Ryan">
      <organization>Disney Streaming</organization>
      <address>
        <postal>
          <street>1211 Avenue of the Americas</street>
          <city>New York</city>
          <region>NY</region>
          <code>10036</code>
          <country>United States of America</country>
        </postal>
        <email>andrew@andrewnryan.com</email>
      </address>
    </author>
    <author fullname="Ben Rosenblum" initials="B." surname="Rosenblum">
      <organization>Vecima</organization>
      <address>
        <postal>
          <street>4375 River Green Pkwy #100</street>
          <city>Duluth</city>
          <region>GA</region>
          <code>30096</code>
          <country>United States of America</country>
        </postal>
        <email>ben@rosenblum.dev</email>
      </address>
    </author>
    <author fullname="Nir B. Sopher" initials="N." surname="Sopher">
      <organization>Qwilt</organization>
      <address>
        <postal>
          <street>6, Ha'harash</street>
          <city>Hod HaSharon</city>
          <code>4524079</code>
          <country>Israel</country>
        </postal>
        <email>nir@apache.org</email>
      </address>
    </author>
    <date month="July" year="2025"/>

    <area>WIT</area>
    <workgroup>cdni</workgroup>

<keyword>cdni</keyword>
<keyword>Capacity</keyword>
<keyword>telemetry</keyword>
<keyword>observability</keyword>

    <abstract>
      <t>This specification defines a set of additional
      Capability Objects that provide information about current downstream
      CDN (dCDN) utilization and specified usage limits to the delegating
      upstream CDN (uCDN) in order to inform traffic delegation decisions.
      </t>
      <t>This document supplements the CDNI Capability Objects, defined in
      RFC 8008 as part of the Footprint &amp; Capabilities Advertisement
      Interface (FCI), with two additional Capability Objects:
      FCI.CapacityLimits and FCI.Telemetry.
      </t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>
                While delegating traffic from an upstream CDN (uCDN) to a
                downstream CDN (dCDN), it is important to ensure that an
                appropriate amount of traffic is delegated. To achieve that,
                this specification defines a feedback mechanism to inform the
                delegator how much traffic may be delegated. The traffic
                level information provided by that interface will be consumed
                by services, such as a request router, to inform that
                service's traffic delegation decisions. The provided information is advisory and does not represent a
                guarantee, commitment, or reservation of capacity.
      </t>
      <t>
                This document defines and registers CDNI Payload Types (as defined in <xref section="7.1" target="RFC8006" format="default"/>). These Payload Types
                are used for Capability Objects, which are added to those defined in <xref section="4" target="RFC8008" format="default"/>.
      </t>
      <section anchor="terminology" numbered="true" toc="default">
        <name>Terminology</name>
        <t>The following term is used throughout this document:</t>
        <dl spacing="normal" newline="false">
	  <dt>CDN:</dt><dd>Content Delivery Network</dd>
	</dl>
        <t>Additionally, this document reuses the terminology defined in <xref
        target="RFC6707" format="default"/>.  Specifically, the
        following CDNI acronyms are used:</t>
        <dl spacing="normal" newline="false">
	  <dt>uCDN:</dt><dd>upstream CDN</dd>
	  <dt>dCDN:</dt><dd>downstream CDN</dd>
	</dl>

      </section>
      <section numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document
        are to be interpreted as described in BCP&nbsp;14 <xref
        target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
        appear in all capitals, as shown here.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Objectives</name>
        <t>
                 To enable information exchange between a uCDN and a dCDN regarding acceptable levels of
                 traffic delegation, the following process has been defined:
        </t>
        <t indent="3">
                 In normal operation, a uCDN will communicate with a dCDN, via an interface, to collect and
                 understand any limits that a dCDN has set forth for traffic delegation from a uCDN.  These limits
                 will come in the form of metrics such as bits per second, requests per second, etc.  These limits
                 can be thought of as Not to Exceed (NTE) limits.
        </t>
        <t indent="3">
                 The dCDN should provide access to a Telemetry Source of near real-time metrics that the uCDN can
                 use to track current usage. The uCDN should compare its current usage to the limits the dCDN has
                 put forth and adjust traffic delegation decisions accordingly to keep current usage under the specified
                 limits.
        </t>
        <t indent="3">
                 In summary, the dCDN will inform the uCDN of the amount of
                 traffic that may be delegated. Additionally, it will provide a
                 Telemetry Source aligned with this limit, allowing the uCDN to
                 monitor its current usage against the advertised value. Having
                 a limit and a corresponding Telemetry Source creates an
                 unambiguous definition understood by both parties.
        </t>
        <t>
                 Limits that are communicated from the dCDN to the uCDN should
                 be considered valid based on the Time to Live (TTL) provided by
                 a mechanism of the underlying transport, e.g., an HTTP
                 Cache-Control header. The intention is that the limits would
                 have a long-lived TTL and would represent a reasonable peak
                 utilization limit that the uCDN should target. If the
                 underlying transport does not provide a mechanism for the dCDN
                 to communicate the TTL of the limits, the TTL should be
                 communicated through an out-of-band mechanism agreed upon between
                 the dCDN and uCDN.
        </t>
      </section>
    </section>
    <section anchor="cdni-additional-capability-objects" numbered="true" toc="default">
      <name>CDNI Additional Capability Objects</name>
      <t>
                <xref section="5" target="RFC8008" format="default"/> describes the FCI Capability Advertisement Object, which
                contains a CDNI Capability Object as well as the capability-type (a CDNI Payload Type).
                The section also defines the Capability Objects per such type. Below, we define two additional Capability Objects.
      </t>
      <aside><t>
                Note: In the following sections, the term "mandatory-to-specify"
                is used to convey which properties <bcp14>MUST</bcp14> be included when
                serializing a given capability object.  When
                mandatory-to-specify is defined as a "Yes" for an individual
                property, it means that if the object containing that property
                is included in an FCI message, then the mandatory-to-specify
                property <bcp14>MUST</bcp14> be included.
      </t></aside>
      <section anchor="telemetry-capability-object" numbered="true" toc="default">
        <name>Telemetry Capability Object</name>
        <t>
                    The Telemetry Capability Object advertises a list of
                    Telemetry Sources made available to the uCDN by the dCDN. In
                    this document, telemetry data is being defined as near
                    real-time aggregated metrics of dCDN utilization, such as
                    bits per second egress, and is specific to the uCDN and dCDN
                    traffic delegation relationship.
        </t>
        <t>    
                    Telemetry data is uniquely defined by a source ID, a metric
                    name, and the footprints that are associated with an
                    FCI Capabilities advertisement.  When defining a
                    CapacityLimit, the meaning of a limit might be ambiguous if
                    the uCDN and dCDN are observing telemetry via different data
                    sources. A dCDN-provided Telemetry Source that both parties
                    reference serves as a non-ambiguous metric for use when
                    comparing current usage to a limit.
        </t>
        <t>
                    Telemetry data is important for making informed traffic
                    delegation decisions. Additionally, it is essential in
                    providing visibility of traffic that has been delegated. In
                    situations where there are multiple CDN delegations, a uCDN
                    will need to aggregate the usage information from any dCDNs
                    to which it delegated when asked to provide usage
                    information, otherwise the traffic may seem unaccounted for.
        </t>
        <t>
                    Example: A Content Provider
                    delegates traffic directly to a uCDN, and that uCDN
                    delegates that traffic to a dCDN. When the Content Provider
                    polls the uCDN telemetry interface, any of the traffic the
                    uCDN delegated to the dCDN would
                    become invisible to the Content Provider, unless the uCDN
                    aggregates the dCDN telemetry with its own metrics.
        </t>


	<dl spacing="normal" newline="false">
          <dt>Property:</dt><dd><t>sources</t>
	  <dl spacing="normal" newline="false">
            <dt>Description:</dt><dd>Telemetry Sources made available to the uCDN.</dd>
            <dt>Type:</dt><dd>A JSON array of Telemetry Source objects (see
            <xref target="telemetry-source-object" format="default"/>).</dd>
            <dt>Mandatory-to-Specify:</dt><dd>Yes</dd>
	  </dl>
	</dd>
	</dl>

        <section anchor="telemetry-source-object" numbered="true" toc="default">
          <name>Telemetry Source Object</name>
          <t>The Telemetry Source Object is made of an associated type, a
          list of exposed metrics, and type-specific configuration data.
          </t>

	<dl spacing="normal" newline="false">
          <dt>Property:</dt><dd><t>id</t>
	  <dl spacing="normal" newline="false">
            <dt>Description:</dt><dd>An identifier of a telemetry source.  The
            ID string assigned to this Telemetry Source <bcp14>MUST</bcp14> be
            unique across all Telemetry Source objects in the advertisement
            containing this Telemetry Source Object. The ID string
            <bcp14>MUST</bcp14> remain consistent for the same source
            reference across advertisements.</dd>
            <dt>Type:</dt><dd>String</dd>
            <dt>Mandatory-to-Specify:</dt><dd>Yes</dd>
          </dl>
        </dd>
        <dt>Property:</dt><dd><t>type</t>
	  <dl spacing="normal" newline="false">
            <dt>Description:</dt><dd>A valid Telemetry Source Type (see <xref
            target="telemetry-source-type" format="default"/>).</dd>
            <dt>Type:</dt><dd>String</dd>
            <dt>Mandatory-to-Specify:</dt><dd>Yes</dd>
	  </dl>
	</dd>
        <dt>Property:</dt><dd><t>metrics</t>
	  <dl spacing="normal" newline="false">
            <dt>Description:</dt><dd>The metrics exposed by this source.</dd>
            <dt>Type:</dt><dd>A JSON array of Telemetry Source Metric Objects
            (see <xref target="telemetry-source-metric-object"
            format="default"/>).</dd>
            <dt>Mandatory-to-Specify:</dt><dd>Yes</dd>
	  </dl>
        </dd>
        <dt>Property:</dt><dd><t>configuration</t>
	  <dl spacing="normal" newline="false">
            <dt>Description:</dt><dd>A source-specific representation of the
            Telemetry Source configuration. For the generic source type, this
            configuration format is defined as out-of-band. For other types, the
            configuration format will be specified in a yet-to-be-defined
            telemetry interface specification.  The goal of this element is to
            allow for forward compatibility with a formal telemetry
            interface.</dd>
            <dt>Type:</dt><dd>A JSON object, the structure of which is
            specific to the Telemetry Source and outside the scope of this
            document.</dd>
            <dt>Mandatory-to-Specify:</dt><dd>No</dd>
          </dl>
	</dd>
	</dl>

          <section anchor="telemetry-source-type" numbered="true" toc="default">
            <name>Telemetry Source Types</name>
            <t>
At the time of this writing, the "CDNI Telemetry Source Types" registry
is limited to a single type: generic (see <xref target="table3"/> in <xref target="IANA.cdni.telemetry.generic" format="default"/>).
            </t>

          </section>
          <section anchor="telemetry-source-metric-object" numbered="true" toc="default">
            <name>Telemetry Source Metric Object</name>
            <t> The Telemetry Source Metric Object describes the metric to be
            exposed.
            </t>

	    <dl spacing="normal" newline="false">
              <dt>Property:</dt><dd><t>name</t>
	      <dl spacing="normal" newline="false">
                <dt>Description:</dt><dd>An identifier for this metric. This
                name <bcp14>MUST</bcp14> be unique among metric objects within
                the containing Telemetry Source.  The name <bcp14>MUST</bcp14>
                remain consistent for the same source reference across
                advertisements.</dd>
                <dt>Type:</dt><dd>String</dd>
                <dt>Mandatory-to-Specify:</dt><dd>Yes</dd>
	      </dl>
	    </dd>
            <dt>Property:</dt><dd><t>time-granularity</t>
	      <dl spacing="normal" newline="false">
                <dt>Description:</dt><dd>The time, in seconds, representing
                the metric data. For example, a value representing the last 5
                minutes would have a time-granularity of 300.</dd>
                <dt>Type:</dt><dd>Unsigned Integer</dd>
                <dt>Mandatory-to-Specify:</dt><dd>No</dd>
	      </dl>
	    </dd>
            <dt>Property:</dt><dd><t>data-percentile</t>
	      <dl spacing="normal" newline="false">
                <dt>Description:</dt><dd>The percentile calculation the data
                represents, i.e., 50 percentile would equate to the median
                over the time-granularity.  Lack of a data-percentile
                indicates that the data <bcp14>MUST</bcp14> be the mean over
                the time representation.</dd>
		<dt>Type:</dt><dd>Unsigned Integer</dd>
                <dt>Mandatory-to-Specify:</dt><dd>No</dd>
              </dl>
            </dd>
            <dt>Property:</dt><dd><t>latency</t>
	      <dl spacing="normal" newline="false">
                <dt>Description:</dt><dd>Time in seconds that the data is
                behind real-time.  This is important to specify to help the
                uCDN understand how long it might take to reflect traffic
                adjustments in the metrics.</dd>
                <dt>Type:</dt><dd>Unsigned Integer</dd>
                <dt>Mandatory-to-Specify:</dt><dd>No</dd>
              </dl>
	    </dd>
	    </dl>

          </section>
        </section>
        <section anchor="telemetry-capability-object-serialization" numbered="true" toc="default">
          <name>Telemetry Capability Object Serialization</name>

          <t> The following shows an example of a Telemetry Capability Object,
          including two metrics for a source, that is scoped to 
          a footprint.
          </t>
          <sourcecode type="json"><![CDATA[
{
  "capabilities": [
    {
      "capability-type": "FCI.Telemetry",
      "capability-value": {
        "sources": [
          {
            "id": "capacity_metrics_region1",
            "type": "generic",
            "metrics": [
              {
                "name": "egress_5m",
                "time-granularity": 300,
                "data-percentile": 50,
                "latency": 1500
              },
              {
                "name": "requests_5m",
                 ...
              }
            ]
          }
        ]
      },
      "footprints": [
        <footprint objects>
      ]
    }
  ]
}]]></sourcecode>
        </section>
      </section>
      <section anchor="capacity-limits-capability-object" numbered="true" toc="default">
        <name>CapacityLimits Capability Object</name>
        <t>The CapacityLimits Capability Object enables the dCDN to specify
        traffic delegation limits to a uCDN within an FCI Capabilities
        advertisement.  The limits specified by the dCDN will inform the uCDN
        on how much traffic may be delegated to the dCDN. The limits specified
        by the dCDN should be considered NTE limits. The
        limits should be based on near real-time telemetry data that the dCDN
        provides to the uCDN. In other words, for each limit that is
        advertised, there should also exist a Telemetry Source that provides
        current utilization data against the particular advertised limit.</t>

        <dl spacing="normal" newline="false">
          <dt>Property:</dt><dd><t>limits</t>
            <dl spacing="normal" newline="false">
              <dt>Description:</dt><dd>A collection of CapacityLimit Objects.</dd>
              <dt>Type:</dt><dd>A JSON array of CapacityLimit Objects (see
              <xref target="capacity-limit-object" format="default"/>).</dd>
              <dt>Mandatory-to-Specify:</dt><dd>Yes</dd>
	    </dl>
	  </dd>
	</dl>

        <section anchor="capacity-limit-object" numbered="true" toc="default">
          <name>CapacityLimit Object</name>
          <t>A CapacityLimit Object is used to represent traffic limits for
          delegation from the uCDN towards the dCDN.  The limit object is
          scoped to the footprint associated with the FCI Capabilities
          advertisement encompassing this object. Limits <bcp14>MUST</bcp14>
          be considered using a logical "AND": A uCDN will need to ensure that
          all limits are considered rather than choosing only the most
          specific.
          </t>

        <dl spacing="normal" newline="false">
          <dt>Property:</dt><dd><t>limit-type</t>
            <dl spacing="normal" newline="false">
              <dt>Description:</dt><dd>The units of maximum-hard and maximum-soft.</dd>
              <dt>Type:</dt><dd>String. One of the values listed in <xref target="capacity-limit-type" format="default"/>.</dd>
              <dt>Mandatory-to-Specify:</dt><dd>Yes</dd>
            </dl>
          </dd>
          <dt>Property:</dt><dd><t>id</t>
            <dl spacing="normal" newline="false">
              <dt>Description:</dt><dd>Specifies an identifier associated with
              a limit. This <bcp14>MAY</bcp14> be used as a relational
              identifier to a specific CapacityLimit Object. If specified,
              this identifier <bcp14>MUST</bcp14> be unique among specified
              identifiers associated with any other CapacityLimit Objects in
              the advertisement containing this CapacityLimit Object.</dd>
              <dt>Type:</dt><dd>String</dd>
              <dt>Mandatory-to-Specify:</dt><dd>No</dd>
            </dl>
          </dd>
          <dt>Property:</dt><dd><t>maximum-hard</t>
            <dl spacing="normal" newline="false">
              <dt>Description:</dt><dd>The maximum unit of capacity that is available for use.</dd>
              <dt>Type:</dt><dd>Unsigned Integer</dd>
              <dt>Mandatory-to-Specify:</dt><dd>Yes</dd>
            </dl>
          </dd>
          <dt>Property:</dt><dd><t>maximum-soft</t>
            <dl spacing="normal" newline="false">
              <dt>Description:</dt><dd>A soft limit at which a uCDN
              <bcp14>SHOULD</bcp14> reduce traffic before hitting the hard
              limit. This value <bcp14>MUST</bcp14> be less than the value of
              maximum-hard. If this value is not specified, it is equal to the
              value of maximum-hard.</dd>
              <dt>Type:</dt><dd>Unsigned Integer</dd>
              <dt>Mandatory-to-Specify:</dt><dd>No</dd>
            </dl>
          </dd>
          <dt>Property:</dt><dd><t>current</t>
            <dl spacing="normal" newline="false">
              <dt>Description:</dt><dd>Specifies the current usage value of
              the limit.  It is <bcp14>NOT RECOMMENDED</bcp14> to specify the
              current usage value inline with the FCI.CapacityLimits
              advertisements as it will reduce the ability to cache the
              response, but this mechanism exists for simple use cases where
              an external Telemetry Source cannot be feasibly implemented. The
              intended method for providing telemetry data is to reference a
              Telemetry Source Object (see <xref
              target="telemetry-source-object" format="default"/>) to poll for
              the current usage.</dd>
              <dt>Type:</dt><dd>Unsigned Integer</dd>
              <dt>Mandatory-to-Specify:</dt><dd>No</dd>
            </dl>
          </dd>
          <dt>Property:</dt><dd><t>telemetry-source</t>
            <dl spacing="normal" newline="false">
              <dt>Description:</dt><dd>The mapping of each particular limit to a
              specific metric with relevant real-time data provided by a
              Telemetry Source.</dd>
              <dt>Type:</dt><dd>CapacityLimitTelemetrySource object (see <xref
              target="capacity-limit-telemetry-source-object"
              format="default"/>).</dd>
              <dt>Mandatory-to-Specify:</dt><dd>No</dd>
            </dl>
          </dd>
          </dl>

          <section anchor="capacity-limit-type" numbered="true" toc="default">
            <name>CapacityLimit Types</name>
            <t>Below are listed the valid limit-type entries registered in
            the "CDNI Capacity Limit Types" registry. The values specified here
            represent the types that were identified as being the most
            relevant metrics for the purposes of traffic delegation between
            CDNs.
            </t>
            <table align="center">
              <thead>
                <tr>
                  <th align="left">
                                Capacity Limit Type
                            </th>
                  <th align="left">
                                Units
                            </th>
                </tr>
              </thead>
              <tbody>
                <tr>
                  <td align="left">egress</td>
                  <td align="left">Bits per second</td>
                </tr>
                <tr>
                  <td align="left">requests</td>
                  <td align="left">Requests per second</td>
                </tr>
                <tr>
                  <td align="left">storage-size</td>
                  <td align="left">Total bytes</td>
                </tr>
                <tr>
                  <td align="left">storage-objects</td>
                  <td align="left">Count</td>
                </tr>
                <tr>
                  <td align="left">sessions</td>
                  <td align="left">Count</td>
                </tr>
                <tr>
                  <td align="left">cache-size</td>
                  <td align="left">Total bytes</td>
                </tr>
              </tbody>
            </table>
          </section>
          <section anchor="capacity-limit-telemetry-source-object" numbered="true" toc="default">
            <name>CapacityLimitTelemetrySource Object</name>
            <t> The CapacityLimitTelemetrySource Object refers to a specific
            metric within a Telemetry Source.</t>

            <dl spacing="normal" newline="false">
              <dt>Property:</dt><dd><t>id</t>
                <dl spacing="normal" newline="false">
                  <dt>Description:</dt><dd>Reference to the "id" of a
                  Telemetry Source defined by a Telemetry Capability Object as
                  defined in <xref target="telemetry-capability-object"
                  format="default"/>.</dd>
                  <dt>Type:</dt><dd>String</dd>
                  <dt>Mandatory-to-Specify:</dt><dd>Yes</dd>
                </dl>
              </dd>
              <dt>Property:</dt><dd><t>metric</t>
                <dl spacing="normal" newline="false">
                  <dt>Description:</dt><dd>Reference to the "name" property of
                  a metric defined within a Telemetry Source of a Telemetry
                  Capability object.</dd>
                  <dt>Type:</dt><dd>String</dd>
                  <dt>Mandatory-to-Specify:</dt><dd>Yes</dd>
                </dl>
              </dd>
            </dl>

          </section>
        </section>
        <section anchor="capacity-limit-object-serialization" numbered="true" toc="default">
          <name>CapacityLimit Object Serialization</name>
          <t> The following shows an example of an FCI.CapacityLimits object.</t>

          <sourcecode type="json"><![CDATA[
{
  "capabilities": [
    {
      "capability-type":"FCI.CapacityLimits",
      "capability-value":{
        "limits":[
          {
            "id":"capacity_limit_region1",
            "limit-type":"egress",
            "maximum-hard":50000000000,
            "maximum-soft":25000000000,
            "telemetry-source":{
              "id":"capacity_metrics_region1",
              "metric":"egress_5m"
            }
          }
        ]
      },
      "footprints":[
        "<footprint objects>"
      ]
    }
  ]
}]]></sourcecode>

        </section>
      </section>
    </section>
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="IANA.cdni.payload.types" numbered="true" toc="default">
        <name>CDNI Payload Types</name>
        <t>Per this document, IANA has registered two additional payload
        types in the "CDNI Payload Types" registry within the "Content Delivery Network Interconnection (CDNI) Parameters" registry group:
        </t>
        <table align="center">
          <thead>
            <tr>
              <th align="left">Payload Type</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">FCI.Telemetry</td>
              <td align="left">RFC 9808</td>
            </tr>
            <tr>
              <td align="left">FCI.CapacityLimits</td>
              <td align="left">RFC 9808</td>
            </tr>
          </tbody>
        </table>

        <section anchor="IANA.cdni.fci.telemetry.payload.type" numbered="true" toc="default">
          <name>CDNI FCI.Telemetry Payload Type</name>

          <dl spacing="normal" newline="false">
            <dt>Purpose:</dt><dd>The purpose of this Payload Type is to list
            the supported Telemetry Sources and the metrics made available by
            each source.</dd>
            <dt>Interface:</dt><dd>FCI</dd>
            <dt>Encoding:</dt><dd>See <xref target="telemetry-capability-object" format="default"/>.</dd>
          </dl>

        </section>
        <section anchor="IANA.cdni.fci.capacity.limits.payload.type" numbered="true" toc="default">
          <name>CDNI FCI.CapacityLimits Payload Type</name>

          <dl spacing="normal" newline="false">
            <dt>Purpose:</dt><dd>The purpose of this Payload Type is to define
            Capacity Limits based on utilization metrics corresponding to
            Telemetry Sources provided by the dCDN.</dd>
            <dt>Interface:</dt><dd>FCI</dd>
            <dt>Encoding:</dt><dd>See <xref target="capacity-limits-capability-object" format="default"/>.</dd>
          </dl>

        </section>
      </section>
      <section anchor="IANA.cdni.telemetry.registry" numbered="true" toc="default">
        <name>CDNI Telemetry Source Types Registry</name>
        <t>IANA has added the following new registry within the "Content Delivery
        Network Interconnection (CDNI) Parameters" registry group at
        <eref target="https://www.iana.org/assignments/cdni-parameters" brackets="angle"/>:</t>
	
	<dl spacing="normal" newline="false">
          <dt>Registry Name:</dt><dd>CDNI Telemetry Source Types</dd>
          <dt>Registry Description:</dt><dd>The "CDNI Telemetry Source Types"
          registry defines the valid values for the "type" property of the
          Telemetry Source object defined in <xref
          target="telemetry-source-object" format="default"/>.</dd>
          <dt>Registration Procedure:</dt><dd><t>The registry follows the
          Specification Required policy as defined in <xref target="RFC8126"
          format="default"/>.  The designated expert should consider the
          following guidelines when evaluating registration requests:</t>
          <ul spacing="normal">
            <li>The new type definition does not duplicate existing
            types.</li>
            <li>The review should verify that the Telemetry Source is
            applicable to the CDNI use cases and that the description is clear
            and unambiguous.</li>
            <li>The registration is applicable for general use and is not proprietary.</li>
            <li>The "configuration" property has a fully specified object
            definition with a description of each defined property.</li>
          </ul>
	</dd>
	</dl>

	<t>The following value has been registered:</t>
		
        <table anchor="table3" align="center">
          <thead>
            <tr>
              <th align="left">Source Type</th>
	      <th align="left">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">generic</td>
	      <td>An object that allows for advertisement of generic data sources</td>
              <td align="left">RFC 9808</td>
            </tr>
          </tbody>
        </table>


        <section anchor="IANA.cdni.telemetry.generic" numbered="true" toc="default">
          <name>CDNI Generic Telemetry Source Type</name>

          <dl spacing="normal" newline="false">
            <dt>Purpose:</dt><dd>The purpose of this Telemetry Source Type is
            to provide a source-agnostic telemetry type that may be used for
            generic Telemetry Source advertisement.</dd>
            <dt>Usage:</dt><dd>See <xref target="telemetry-source-object" format="default"/>.</dd>
          </dl>

        </section>
      </section>

      <section anchor="IANA.cdni.capacity.registry" numbered="true" toc="default">
        <name>CDNI Capacity Limit Types Registry</name>
        <t>IANA has added the following new registry within the "Content Delivery
        Network Interconnection (CDNI) Parameters" registry group at
        <eref target="https://www.iana.org/assignments/cdni-parameters" brackets="angle"/>:</t>

	<dl spacing="normal" newline="false">
          <dt>Registry Name:</dt><dd>CDNI Capacity Limit Types</dd>
          <dt>Registry Description:</dt><dd>The "CDNI Capacity Limit Types"
          registry defines the valid values of the "limit-type" property of a
          CapacityLimit Object defined in <xref target="capacity-limit-object"
          format="default"/>.</dd>
          <dt>Registration Procedure:</dt><dd><t>The registry follows the
          Specification Required policy as defined in <xref target="RFC8126"
          format="default"/>.  The designated expert should consider the
          following guidelines when evaluating registration requests:</t>
          <ul spacing="normal">
            <li>The new capacity limit-type does not duplicate existing entries.</li>
            <li>The submission has a defined purpose. The newly defined
            capacity limit-type should be clearly justified in the context of
            one or more CDNI use cases.</li>
            <li>The description of the capacity limit-type is well-documented and unambiguous.</li>
          </ul>
	</dd>
	</dl>
	
        <t>The following values have been registered:</t>
	
        <table align="center">
          <thead>
            <tr>
              <th align="left">Capacity Limit Type</th>
              <th align="left">Units</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">egress</td>
              <td align="left">Bits per second</td>
              <td align="left">RFC 9808</td>
            </tr>
            <tr>
              <td align="left">requests</td>
              <td align="left">Requests per second</td>
              <td align="left">RFC 9808</td>
            </tr>
            <tr>
              <td align="left">storage-size</td>
              <td align="left">Total bytes</td>
              <td align="left">RFC 9808</td>
            </tr>
            <tr>
              <td align="left">storage-objects</td>
              <td align="left">Count</td>
              <td align="left">RFC 9808</td>
            </tr>
            <tr>
              <td align="left">sessions</td>
              <td align="left">Count</td>
              <td align="left">RFC 9808</td>
            </tr>
            <tr>
              <td align="left">cache-size</td>
              <td align="left">Total bytes</td>
              <td align="left">RFC 9808</td>
            </tr>
          </tbody>
        </table>

	<dl spacing="normal" newline="false">	
        <dt>Usage:</dt><dd>See <xref target="capacity-limit-type" format="default"/>.</dd>
	</dl>
      </section>
    </section>
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This specification is in accordance with the CDNI Request Routing:
      Footprint and Capabilities Semantics. As such, it is subject to the
      security and privacy considerations as defined in <xref
      section="7" target="RFC8008" format="default"/>.
      </t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8008.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8006.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6707.xml"/>

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

      </references>
    </references>

    <section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to express their gratitude to the members of
      the Streaming Video Technology Alliance <xref target="SVTA"
      format="default"/> Open Caching Working Group for their guidance,
      contribution, and review.
      </t>
    </section>

  </back>


</rfc>
