rfc9808xml2.original.xml   rfc9808.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="4"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<?rfc compact="yes"?> tf-cdni-capacity-insights-extensions-12" number="9808" consensus="true" ipr="tru
<rfc category="std" docName="draft-ietf-cdni-capacity-insights-extensions-12" ip st200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude
r="trust200902"> ="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
<front>
<title abbrev="CDNI Capacity Capability Advertisement Extensions"> <front>
CDNI Capacity Capability Advertisement Extensions <title abbrev="CDNI Capacity Capability Advertisement Extensions">Content De
</title> livery Network Interconnection (CDNI)
<author fullname="Andrew Ryan" initials="A." surname="Ryan"> Capacity Capability Advertisement Extensions</title>
<organization> <seriesInfo name="RFC" value="9808"/>
Disney Streaming <author fullname="Andrew Ryan" initials="A." surname="Ryan">
</organization> <organization>Disney Streaming</organization>
<address> <address>
<postal> <postal>
<street> <street>1211 Avenue of the Americas</street>
1211 Avenue of the Americas <city>New York</city>
</street> <region>NY</region>
<city> <code>10036</code>
New York <country>United States of America</country>
</city> </postal>
<region> <email>andrew@andrewnryan.com</email>
NY </address>
</region> </author>
<code> <author fullname="Ben Rosenblum" initials="B." surname="Rosenblum">
10036 <organization>Vecima</organization>
</code> <address>
<country> <postal>
US <street>4375 River Green Pkwy #100</street>
</country> <city>Duluth</city>
</postal> <region>GA</region>
<email> <code>30096</code>
andrew@andrewnryan.com <country>United States of America</country>
</email> </postal>
</address> <email>ben@rosenblum.dev</email>
</author> </address>
<author fullname="Ben Rosenblum" initials="B." surname="Rosenblum"> </author>
<organization> <author fullname="Nir B. Sopher" initials="N." surname="Sopher">
Vecima <organization>Qwilt</organization>
</organization> <address>
<address> <postal>
<postal> <street>6, Ha'harash</street>
<street> <city>Hod HaSharon</city>
4375 River Green Pkwy #100 <code>4524079</code>
</street> <country>Israel</country>
<city> </postal>
Duluth <email>nir@apache.org</email>
</city> </address>
<region> </author>
GA <date month="June" year="2025"/>
</region>
<code> <area>WIT</area>
30096 <workgroup>cdni</workgroup>
</code>
<country> <!-- [rfced] Please insert any keywords (beyond those that appear in
US the title) for use on https://www.rfc-editor.org/search. -->
</country>
</postal> <keyword>example</keyword>
<email>
ben@rosenblum.dev <!-- [rfced] Do the extensions define or does this specification define "a set
</email> of additional Capability Objects..."?
</address>
</author> Current:
<author fullname="Nir B. Sopher" initials="N." surname="Sopher"> The Content Delivery Network Interconnection (CDNI) Capacity
<organization> Capability Advertisement Extensions define a set of additional
Qwilt Capability Objects that provide information about current downstream
</organization> CDN (dCDN) utilization and specified usage limits to the delegating
<address> upstream CDN (uCDN) in order to inform traffic delegation decisions.
<postal>
<street> Perhaps:
6, Ha'harash This specification defines a set of additional
</street> Capability Objects that provide information about current downstream
<city> CDN (dCDN) utilization and specified usage limits to the delegating
Hod HaSharon upstream CDN (uCDN) in order to inform traffic delegation decisions.
</city> -->
<region>
</region> <abstract>
<code> <t>The Content Delivery Network Interconnection (CDNI) Capacity
4524079 Capability Advertisement Extensions define a set of additional
</code> Capability Objects that provide information about current downstream CDN
<country> (dCDN) utilization and specified usage limits to the delegating upstream
Israel CDN (uCDN) in order to inform traffic delegation decisions.
</country> </t>
</postal> <t>This document supplements the CDNI Capability Objects, defined in
<email> RFC 8008 as part of the Footprint &amp; Capabilities Advertisement
nir@apache.org Interface (FCI), with two additional Capability Objects:
</email> FCI.CapacityLimits and FCI.Telemetry.
</address> </t>
</author> </abstract>
<date /> </front>
<workgroup>Content Delivery Networks Interconnection</workgroup> <middle>
<abstract> <section numbered="true" toc="default">
<t> <name>Introduction</name>
The Content Delivery Networks Interconnection (CDNI) Capacity <t>
Capability Advertisement Extensions define 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 i
n
RFC 8008 as part of the Footprints &amp; Capabilities
Advertisement Interface (FCI), with two additional Capability
Objects: FCI.CapacityLimits and FCI.Telemetry.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
While delegating traffic from an upstream CDN (uCDN) to a While delegating traffic from an upstream CDN (uCDN) to a
downstream CDN (dCDN), it is important to ensure that an downstream CDN (dCDN), it is important to ensure that an
appropriate amount of traffic is delegated. To achieve that, appropriate amount of traffic is delegated. To achieve that,
this specification defines a feedback mechanism to inform the this specification defines a feedback mechanism to inform the
delegator how much traffic may be delegated. The traffic delegator how much traffic may be delegated. The traffic
level information provided by that interface will be consumed level information provided by that interface will be consumed
by services, such as a request router, to inform that 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 service's traffic delegation decisions. The provided information is advisory and does not represent a
guarantee, commitment, or reservation of capacity. guarantee, commitment, or reservation of capacity.
</t> </t>
<t> <t>
This document defines and registers CDNI Payload Types (as defin This document defines and registers CDNI Payload Types (as defin
ed ed in <xref section="7.1" target="RFC8006" format="default"/>). These Payload ty
at section 7.1 of <xref target="RFC8006" />). These Payload type pes
s are used for Capability Objects, which are added to those define
are used for Capability Objects added to those defined at sectio d in <xref section="4" target="RFC8008" format="default"/>.
n 4 </t>
of <xref target="RFC8008" />. <section anchor="terminology" numbered="true" toc="default">
</t> <name>Terminology</name>
<section anchor="terminology" title="Terminology"> <t>The following term is used throughout this document:</t>
<t> <dl spacing="normal" newline="false">
The following terms are used throughout this document: <dt>CDN:</dt><dd>Content Delivery Network</dd>
<list style="symbols"> </dl>
<t> <t>Additionally, this document reuses the terminology defined in <xref
CDN - Content Delivery Network target="RFC6707" format="default"/>. Specifically, the
</t> following CDNI acronyms are used:</t>
</list> <dl spacing="normal" newline="false">
</t> <dt>uCDN:</dt><dd>upstream CDN</dd>
<t> <dt>dCDN:</dt><dd>downstream CDN</dd>
Additionally, this document reuses the terminology defined i </dl>
n
<xref target="RFC6707" />. </section>
Specifically, we use the following CDNI acronyms: <section numbered="true" toc="default">
<list style="symbols"> <name>Requirements Language</name>
<t> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
uCDN, dCDN - Upstream CDN and Downstream CDN, respec "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
tively NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
</list> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
</t> are to be interpreted as described in BCP&nbsp;14 <xref
</section> target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
<section title="Requirements Language"> appear in all capitals, as shown here.
<t> </t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHAL </section>
L NOT", "SHOULD", <section numbered="true" toc="default">
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and " <name>Objectives</name>
OPTIONAL" in this <t>
document are to be interpreted as described in BCP 14
<xref target="RFC2119" />
<xref target="RFC8174" />
when, and only when, they appear in all capitals, as shown h
ere.
</t>
</section>
<section title="Objectives">
<t>
To enable information exchange between a uCDN and a dCDN regard ing acceptable levels of To enable information exchange between a uCDN and a dCDN regard ing acceptable levels of
traffic delegation, the following process has been defined: traffic delegation, the following process has been defined:
</t> </t>
<t indent="3">
<t> In normal operation, a uCDN will communicate with a dCDN, via a
In normal operation a uCDN will communicate with a dCDN, via an n interface, to collect and
interface, to collect and
understand any limits that a dCDN has set forth for traffic del egation from a uCDN. These limits understand any limits that a dCDN has set forth for traffic del egation from a uCDN. These limits
will come in the form of metrics such as bits per second, reque sts per second, etc. These limits will come in the form of metrics such as bits per second, reque sts per second, etc. These limits
can be thought of as Not to Exceed (NTE) limits. can be thought of as Not to Exceed (NTE) limits.
</t> </t>
<t indent="3">
<t>
The dCDN should provide access to a telemetry source of near re al-time metrics that the uCDN can The dCDN should provide access to a telemetry source of near re al-time metrics that the uCDN can
use to track current usage. The uCDN should compare its current usage to the limits the dCDN has 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 t o keep current usage under the specified put forth and adjust traffic delegation decisions accordingly t o keep current usage under the specified
limits. limits.
</t> </t>
<t indent="3">
<t>
In summary, the dCDN will inform the uCDN of the amount of In summary, the dCDN will inform the uCDN of the amount of
traffic that may be delegated. Additionally, it will provide a traffic that may be delegated. Additionally, it will provide a
telemetry source aligned with this limit, allowing the uCDN to telemetry source aligned with this limit, allowing the uCDN to
monitor its current usage against the advertised value. Having monitor its current usage against the advertised value. Having
a limit and a corresponding telemetry source creates an a limit and a corresponding telemetry source creates an
unambiguous definition understood by both parties. unambiguous definition understood by both parties.
</t> </t>
<t>
<t>
Limits that are communicated from the dCDN to the uCDN should Limits that are communicated from the dCDN to the uCDN should
be considered valid based on the TTL (Time To Live) provided by be considered valid based on the Time to Live (TTL) provided by
a mechanism of the underlying transport, e.g., an HTTP a mechanism of the underlying transport, e.g., an HTTP
Cache-Control header. The intention is that the limits would Cache-Control header. The intention is that the limits would
have a long-lived TTL and would represent a reasonable peak have a long-lived TTL and would represent a reasonable peak
utilization limit that the uCDN should target. If the utilization limit that the uCDN should target. If the
underlying transport does not provide a mechanism for the dCDN underlying transport does not provide a mechanism for the dCDN
to communicate the TTL of the limits, the TTL should be to communicate the TTL of the limits, the TTL should be
communicated through an out-of-band mechanism agrred between communicated through an out-of-band mechanism agreed upon betwe en
the dCDN and uCDN. the dCDN and uCDN.
</t> </t>
</section> </section>
</section> </section>
<section anchor="cdni-additional-capability-objects" title="CDNI Additio <section anchor="cdni-additional-capability-objects" numbered="true" toc="de
nal Capability Objects"> fault">
<t> <name>CDNI Additional Capability Objects</name>
Section 5 of <xref target="RFC8008" /> describes the FCI Capabil <t>
ity Advertisement Object, which <xref section="5" target="RFC8008" format="default"/> describes
the FCI Capability Advertisement Object, which
contains a CDNI Capability Object as well as the capability obje ct type (a CDNI Payload Type). contains a CDNI Capability Object as well as the capability obje ct type (a CDNI Payload Type).
The section also defines the Capability Objects per such type. B elow, we define two additional Capability Objects. The section also defines the Capability Objects per such type. B elow, we define two additional Capability Objects.
</t> </t>
<t> <t>
Note: In the following sections, the term "mandatory-to-specify" Note: In the following sections, the term "mandatory-to-specify"
is used to convey which properties MUST be included when is used to convey which properties <bcp14>MUST</bcp14> be includ ed when
serializing a given capability object. When serializing a given capability object. When
mandatory-to-specify is defined as a "Yes" for an individual mandatory-to-specify is defined as a "Yes" for an individual
property, it means that if the object containing that property property, it means that if the object containing that property
is included in an FCI message, then the mandatory-to-specify is included in an FCI message, then the mandatory-to-specify
property MUST be included. property <bcp14>MUST</bcp14> be included.
</t> </t>
<section anchor="telemetry-capability-object" title="Telemetry Capab <section anchor="telemetry-capability-object" numbered="true" toc="default
ility Object"> ">
<t> <name>Telemetry Capability Object</name>
<t>
The Telemetry Capability Object advertises a list of The Telemetry Capability Object advertises a list of
telemetry sources made available to the uCDN by the dCDN. In telemetry sources made available to the uCDN by the dCDN. In
this document, telemetry data is being defined as near this document, telemetry data is being defined as near
real-time aggregated metrics of dCDN utilization, such as real-time aggregated metrics of dCDN utilization, such as
bits per second egress, and is specific to the uCDN and dCDN bits per second egress, and is specific to the uCDN and dCDN
traffic delegation relationship. traffic delegation relationship.
</t> </t>
<t> <t>
Telemetry data is uniquely defined by a source ID, a metric Telemetry data is uniquely defined by a source ID, a metric
name, and the footprints that are associated with an name, and the footprints that are associated with an
FCI.Capability advertisement. When defining a FCI.Capability advertisement. When defining a
CapacityLimit, the meaning of a limit might be ambiguous if CapacityLimit, the meaning of a limit might be ambiguous if
the uCDN and dCDN are observing telemetry via different data the uCDN and dCDN are observing telemetry via different data
sources. A dCDN-provided telemetry source that both parties sources. A dCDN-provided telemetry source that both parties
reference serves as a non-ambiguous metric for use when reference serves as a non-ambiguous metric for use when
comparing current usage to a limit. comparing current usage to a limit.
</t> </t>
<t> <t>
Telemetry data is important for making informed traffic Telemetry data is important for making informed traffic
delegation decisions. Additionally, it is essential in delegation decisions. Additionally, it is essential in
providing visibility of traffic that has been delegated. In providing visibility of traffic that has been delegated. In
situations where there are multiple CDN delegations, a uCDN situations where there are multiple CDN delegations, a uCDN
will need to aggregate the usage information from any dCDNs will need to aggregate the usage information from any dCDNs
to which it delegated when asked to provide usage to which it delegated when asked to provide usage
information, otherwise the traffic may seem unaccounted for. information, otherwise the traffic may seem unaccounted for.
</t> </t>
<t> <t>
Example: A Content Provider Example: A Content Provider
delegates traffic directly to a uCDN, and that uCDN delegates traffic directly to a uCDN, and that uCDN
delegates that traffic to a dCDN. When the Content Provider delegates that traffic to a dCDN. When the Content Provider
polls the uCDN telemetry interface, any of the traffic the polls the uCDN telemetry interface, any of the traffic the
uCDN delegated to the dCDN would uCDN delegated to the dCDN would
become invisible to the Content Provider unless the uCDN become invisible to the Content Provider, unless the uCDN
aggregates the dCDN telemetry with its own metrics. aggregates the dCDN telemetry with its own metrics.
</t> </t>
<t><list style="empty"> <!--[rfced] There are several lists for properties throughout the
<t>Property: sources<list style="empty"> document. If the "Type" and "Mandatory-to-Specify" fields only
<t>Description: Telemetry sources made available to the contain one word and a period, may we remove the period? We note
uCDN.</t> that this document follows the formatting style in RFC 8008;
<t>Type: A JSON array of Telemetry Source objects (see < however, our current practice is to remove the punctuation if a
xref target="telemetry-source-object"/>).</t> description only contains one word (see similar examples in RFCs
<t>Mandatory-to-Specify: Yes.</t> 9538 and 9677). Please let us know your preference.
</list></t>
</list></t>
<section anchor="telemetry-source-object" title="Telemetry Sourc One example
e Object">
<t>
The Telemetry Source Object is built of an associated ty
pe, a list of exposed metrics, and type-specific configuration data.
</t>
<t><list style="empty"> Current:
<t>Property: id<list style="empty"> Property: type
<t>Description: An identifier of a telemetry source.
The ID string assigned to this Telemetry Source MUST
be unique across all Telemetry Source objects in the
advertisement containining this Telemetry Source
Object. The ID string MUST remain consistent for
the same source reference across advertisements.</t>
<t>Type: String.</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
<t>Property: type<list style="empty"> Description: A valid telemetry source type (see Section 2.1.1.1).
<t>Description: A valid telemetry source type. See <
xref target="telemetry-source-type"/>.</t>
<t>Type: String.</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
<t>Property: metrics<list style="empty"> Type: String.
<t>Description: The metrics exposed by this source.<
/t>
<t>Type: A JSON array of Telemetry Source Metric obj
ects (see <xref target="telemetry-source-metric-object"/>).</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
<t>Property: configuration<list style="empty"> Mandatory-to-Specify: Yes.
<t>Description: a source-specific representation of
the Telemetry Source configuration. For the generic source type, Perhaps:
this configuration format is defined out-of-band. Property: type
For other types, the configuration format will be specified in
a yet to be defined telemetry interface specifica Description: A valid telemetry source type (see Section 2.1.1.1).
tion. The goal of this element is to allow for forward compatibility
with a formal telemetry interface.</t> Type: String
<t>Type: A JSON object, the structure of which is sp
ecific to the Telemetry Source and outside the scope of this document.</t> Mandatory-to-Specify: Yes
<t>Mandatory-to-Specify: No.</t> -->
</list></t>
</list></t> <dl spacing="normal" newline="false">
<section anchor="telemetry-source-type" title="Telemetry Sou <dt>Property:</dt><dd><t>sources</t>
rce Types"> <dl spacing="normal" newline="false">
<t> <dt>Description:</dt><dd>Telemetry sources made available to the uCD
N.</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 registry of valid At the time of this writing, the registry of valid
Telemetry Source Object types is limited to a single Telemetry Source Types is limited to a single
type: Generic (see <xref target="IANA.cdni.telemetry type: generic (see <xref target="IANA.cdni.telemetry
.generic"/>). .generic" format="default"/>).
</t> </t>
<texttable> <table align="center">
<ttcol align="left"> <thead>
<tr>
<th align="left">
Source Type Source Type
</ttcol> </th>
<ttcol align="left"> <th align="left">
Description Description
</ttcol> </th>
<c>generic</c><c>An object which allows for advertis </tr>
ement of generic data sources</c> </thead>
</texttable> <tbody>
</section> <tr>
<section anchor="telemetry-source-metric-object" title="Tele <td align="left">generic</td>
metry Source Metric Object"> <td align="left">An object that allows for advertisement of ge
<t> neric data sources</td>
The Telemetry Source Metric Object describes the met </tr>
ric to be exposed. </tbody>
</t> </table>
<t><list style="empty"> </section>
<t>Property: name<list style="empty"> <section anchor="telemetry-source-metric-object" numbered="true" toc="
<t>Description: An identifier for this metric. T default">
his name MUST be unique among metric objects within the containing Telemetry Sou <name>Telemetry Source Metric Object</name>
rce. <t> The Telemetry Source Metric Object describes the metric to be
The name MUST remain consistent for the same exposed.
source reference across advertisements.</t> </t>
<t>Type: String.</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
<t>Property: time-granularity<list style="empty"> <dl spacing="normal" newline="false">
<t>Description: The time, in seconds, represent <dt>Property:</dt><dd><t>name</t>
ing the metric data. For example, a value representing the last 5 minutes would <dl spacing="normal" newline="false">
have a time-granularity of 300.</t> <dt>Description:</dt><dd>An identifier for this metric. This
<t>Type: Unsigned Integer.</t> name <bcp14>MUST</bcp14> be unique among metric objects within
<t>Mandatory-to-Specify: No.</t> the containing Telemetry Source. The name <bcp14>MUST</bcp14>
</list></t> 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>
<t>Property: data-percentile<list style="empty"> </section>
<t>Description: The percentile calculation the d </section>
ata represents, i.e., 50 percentile would equate to the median over the time-gra <section anchor="telemetry-capability-object-serialization" numbered="tr
nularity. ue" toc="default">
Lack of a data-percentile indicates that the <name>Telemetry Capability Object Serialization</name>
data MUST be the mean over the time representation.</t>
<t>Type: Unsigned Integer.</t>
<t>Mandatory-to-Specify: No.</t>
</list></t>
<t>Property: latency<list style="empty"> <!--[rfced] For consistency, should "Telemetry Capability" be updated
<t>Description: Time in seconds that the data is as "the Telemetry Capability Object" in the following sentence?
behind real-time. This is important to specify to help the uCDN
understand how long it might take to reflect Original:
traffic adjustments in the metrics.</t> The following shows an example of a Telemetry Capability
<t>Type: Unsigned Integer.</t> including two metrics for a source, that is scoped to
<t>Mandatory-to-Specify: No.</t> a footprint.
</list></t>
</list></t> Perhaps:
</section> The following shows an example of a Telemetry Capability Object,
</section> including two metrics for a source, that is scoped to
<section anchor="telemetry-capability-object-serialization" titl a footprint.
e="Telemetry Capability Object Serialization"> -->
<t>
The following shows an example of Telemetry Capability i <t> The following shows an example of Telemetry Capability including
ncluding two metrics for a source, that is scoped to a footprint. two metrics for a source, that is scoped to a footprint.
</t> </t>
<figure> <sourcecode type=""><![CDATA[
<sourcecode>
<![CDATA[
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "FCI.Telemetry", "capability-type": "FCI.Telemetry",
"capability-value": { "capability-value": {
"sources": [ "sources": [
{ {
"id": "capacity_metrics_region1", "id": "capacity_metrics_region1",
"type": "generic", "type": "generic",
"metrics": [ "metrics": [
skipping to change at line 393 skipping to change at line 456
} }
] ]
} }
] ]
}, },
"footprints": [ "footprints": [
<footprint objects> <footprint objects>
] ]
} }
] ]
} }]]></sourcecode>
]]> </section>
</sourcecode> </section>
</figure> <section anchor="capacity-limits-capability-object" numbered="true" toc="d
</section> efault">
</section> <name>CapacityLimits Capability Object</name>
<t>The CapacityLimits Capability Object enables the dCDN to specify
<section anchor="capacity-limits-capability-object" title="CapacityL traffic delegation limits to a uCDN within an FCI.Capabilities
imits Capability Object"> advertisement. The limits specified by the dCDN will inform the uCDN
<t> on how much traffic may be delegated to the dCDN. The limits specified
The CapacityLimits Capability Object enables the dCDN to spe by the dCDN should be considered NTE limits. The
cify traffic delegation limits limits should be based on near real-time telemetry data that the dCDN
to a uCDN within an FCI.Capabilities advertisement. The lim provides to the uCDN. In other words, for each limit that is
its specified by the dCDN will inform advertised, there should also exist a telemetry source that provides
the uCDN on how much traffic may be delegated to the dCDN. T current utilization data against the particular advertised limit.</t>
he limits specified by the dCDN
should be considered Not To Exceed (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 which
provides current utilization data
against the particular advertised limit.
</t>
<t><list style="empty">
<t>Property: limits<list style="empty">
<t>Description: A collection of CapacityLimit objects.</
t>
<t>Type: A JSON array of CapacityLimit objects (see <xre
f target="capacity-limit-object"/>).</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list></t>
<section anchor="capacity-limit-object" title="CapacityLimit Obj
ect">
<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 capability advertisement encompassing this
object. Limits MUST 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>
<t><list style="empty">
<t>Property: limit-type<list style="empty">
<t>Description: The units of maximum-hard and maximu
m-soft.</t>
<t>Type: String. One of the values listed in <xref t
arget="capacity-limit-type"/>.</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
<t>Property: id<list style="empty"> <dl spacing="normal" newline="false">
<t>Description: Specifies an identifier associated <dt>Property:</dt><dd><t>limits</t>
with a limit. This MAY be used as a relational <dl spacing="normal" newline="false">
identifier to a specific CapacityLimit Object. If <dt>Description:</dt><dd>A collection of CapacityLimit objects.</d
specified, this identifier MUST be unique among d>
specified identifiers associated with any other <dt>Type:</dt><dd>A JSON array of CapacityLimit objects (see
CapacityLimit objects in the advertisement <xref target="capacity-limit-object" format="default"/>).</dd>
containing this CapacityLimit Object.</t> <dt>Mandatory-to-Specify:</dt><dd>Yes.</dd>
<t>Type: String.</t> </dl>
<t>Mandatory-to-Specify: No.</t> </dd>
</list></t> </dl>
<t>Property: maximum-hard<list style="empty"> <section anchor="capacity-limit-object" numbered="true" toc="default">
<t>Description: The maximum unit of capacity that is <name>CapacityLimit Object</name>
available for use.</t> <t>A CapacityLimit object is used to represent traffic limits for
<t>Type: Unsigned Integer.</t> delegation from the uCDN towards the dCDN. The limit object is
<t>Mandatory-to-Specify: Yes.</t> scoped to the footprint associated with the FCI capability
</list></t> 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>
<t>Property: maximum-soft<list style="empty"> <dl spacing="normal" newline="false">
<t>Description: A soft limit at which a uCDN SHOULD <dt>Property:</dt><dd><t>limit-type</t>
reduce <dl spacing="normal" newline="false">
traffic before hitting the hard limit. This value MU <dt>Description:</dt><dd>The units of maximum-hard and maximum-sof
ST t.</dd>
be less than the value of maximum-hard. If this valu <dt>Type:</dt><dd>String. One of the values listed in <xref target
e is not specified, it is equal ="capacity-limit-type" format="default"/>.</dd>
to the value of maximum-hard.</t> <dt>Mandatory-to-Specify:</dt><dd>Yes.</dd>
<t>Type: Unsigned Integer.</t> </dl>
<t>Mandatory-to-Specify: No.</t> </dd>
</list></t> <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 avai
lable 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>
<t>Property: current<list style="empty"> <section anchor="capacity-limit-type" numbered="true" toc="default">
<t>Description: Specifies the current usage value of <name>CapacityLimit Types</name>
the limit. It is NOT RECOMMENDED to specify the current usage <t>Below are listed the valid capacity limit-types registered in
value inline with the FCI.CapacityLimits advertis the "CDNI Capacity Limit Types" registry. The values specified here
ements as it will reduce the ability to cache the response, but this represent the types that were identified as being the most
mechanism exists for simple use cases where an ex relevant metrics for the purposes of traffic delegation between
ternal telemetry source cannot be feasibly implemented. The CDNs.
intended method for providing telemetry data is t </t>
o reference a Telemetry Source object <table align="center">
(see <xref target="telemetry-source-object"/>) to <thead>
poll for the current usage.</t> <tr>
<t>Type: Unsigned Integer.</t> <th align="left">
<t>Mandatory-to-Specify: No.</t> Capacity Limit Type
</list></t> </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="tru
e" toc="default">
<name>CapacityLimitTelemetrySource Object</name>
<t> The CapacityLimitTelemetrySource Object refers to a specific
metric within a Telemetry Source.</t>
<t>Property: telemetry-source<list style="empty"> <dl spacing="normal" newline="false">
<t>Description: Mapping of each particular limit to <dt>Property:</dt><dd><t>id</t>
a specific metric with relevant real-time data provided by <dl spacing="normal" newline="false">
a telemetry source.</t> <dt>Description:</dt><dd>Reference to the "id" of a
<t>Type: CapacityLimitTelemetrySource object (see <x telemetry source defined by a Telemetry Capability object as
ref target="capacity-limit-telemetry-source-object"/>).</t> defined in <xref target="telemetry-capability-object"
<t>Mandatory-to-Specify: No.</t> format="default"/>.</dd>
</list></t> <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>
</list></t> </section>
<section anchor="capacity-limit-type" title="CapacityLimit T </section>
ypes"> <section anchor="capacity-limit-object-serialization" numbered="true" to
<t> c="default">
Below are listed the valid capacity limit-types <name>CapacityLimit Object Serialization</name>
registered in the CDNI Capacity Limit Types <t> The following shows an example of an FCI.CapacityLimits object.</t
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>
<texttable>
<ttcol align="left">
Limit Type
</ttcol>
<ttcol align="left">
Units
</ttcol>
<c>egress</c><c>Bits per second</c>
<c>requests</c><c>Requests per second</c>
<c>storage-size</c><c>Total bytes</c>
<c>storage-objects</c><c>Count</c>
<c>sessions</c><c>Count</c>
<c>cache-size</c><c>Total bytes</c>
</texttable>
</section>
<section anchor="capacity-limit-telemetry-source-object" tit
le="CapacityLimitTelemetrySource Object">
<t>
The CapacityLimitTelemetrySource Object refers to a
specific metric within a Telemetry Source.
</t>
<t><list style="empty">
<t>Property: id<list style="empty">
<t>Description: Reference to the "id" of a telem
etry source defined by a Telemetry Capability
object as defined in <xref target="telemetry-cap
ability-object"/>.</t>
<t>Type: String.</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
<t>Property: metric<list style="empty"> <sourcecode type=""><![CDATA[
<t>Description: Reference to the "name" propert
y of a metric defined within a telemetry source of a
Telemetry Capability object.</t>
<t>Type: String.</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="capacity-limit-object-serialization" title="Cap
acityLimit Object Serialization">
<t>
The following shows an example of an FCI.CapacityLimits
object.
</t>
<figure>
<sourcecode>
<![CDATA[
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type":"FCI.CapacityLimits", "capability-type":"FCI.CapacityLimits",
"capability-value":{ "capability-value":{
"limits":[ "limits":[
{ {
"id":"capacity_limit_region1", "id":"capacity_limit_region1",
"limit-type":"egress", "limit-type":"egress",
"maximum-hard":50000000000, "maximum-hard":50000000000,
skipping to change at line 555 skipping to change at line 664
"metric":"egress_5m" "metric":"egress_5m"
} }
} }
] ]
}, },
"footprints":[ "footprints":[
"<footprint objects>" "<footprint objects>"
] ]
} }
] ]
} }]]></sourcecode>
]]>
</sourcecode>
</figure>
</section>
</section>
</section> </section>
<section anchor="IANA" title="IANA Considerations"> </section>
<section anchor="IANA.cdni.payload.types" title="CDNI Payload Types" </section>
> <section anchor="IANA" numbered="true" toc="default">
<t> <name>IANA Considerations</name>
This document requests the registration of two additional pa <section anchor="IANA.cdni.payload.types" numbered="true" toc="default">
yload types to the Content Delivery Network Interconnection (CDNI) Parameters "C <name>CDNI Payload Types</name>
DNI Payload Types" registry: <t>Per this document, IANA has registered two additional payload
</t> types in the "CDNI Payload Types" registry within the "Content Delivery
<texttable> Network Interconnection (CDNI) Parameters" registry group:
<ttcol align="left"> </t>
Payload Type <table align="center">
</ttcol> <thead>
<ttcol align="left"> <tr>
Specification <th align="left">Payload Type</th>
</ttcol> <th align="left">Reference</th>
<c>FCI.Telemetry</c><c>RFCthis</c> </tr>
<c>FCI.CapacityLimits</c><c>RFCthis</c> </thead>
</texttable> <tbody>
<t> <tr>
[RFC Editor: Please replace RFCthis with the published RFC <td align="left">FCI.Telemetry</td>
number for this document.] <td align="left">RFC 9808</td>
</t> </tr>
<section anchor="IANA.cdni.fci.telemetry.payload.type" title="CD <tr>
NI FCI Telemetry Payload Type"> <td align="left">FCI.CapacityLimits</td>
<t><list style="empty"> <td align="left">RFC 9808</td>
<t>Purpose: The purpose of this Payload Type is to list </tr>
the supported telemetry sources </tbody>
and the metrics made available by each source.</t> </table>
<t>Interface: FCI.</t>
<t>Encoding: See <xref target="telemetry-capability-obje
ct"/>.</t>
</list></t>
</section>
<section anchor="IANA.cdni.fci.capacity.limits.payload.type" tit
le="CDNI FCI Capacity Limits Payload Type">
<t><list style="empty">
<t>Purpose: The purpose of this Payload Type is to defin
e Capacity Limits based on utilization metrics
corresponding to telemetry sources provided by the dCDN.
</t>
<t>Interface: FCI.</t>
<t>Encoding: See <xref target="capacity-limits-capabilit
y-object"/>.</t>
</list></t>
</section>
</section>
<section anchor="IANA.cdni.telemetry.registry" title="&quot;CDNI Tel <section anchor="IANA.cdni.fci.telemetry.payload.type" numbered="true" t
emetry Source Types&quot; Registry"> oc="default">
<t> <name>CDNI FCI Telemetry Payload Type</name>
IANA will add the following new registry to the "Content Del
ivery Network Interconnection (CDNI) Parameters" group at https://www.iana.org/a <dl spacing="normal" newline="false">
ssignments/cdni-parameters: <dt>Purpose:</dt><dd>The purpose of this Payload Type is to list
</t> the supported telemetry sources and the metrics made available by
<t>Registry Name: CDNI Telemetry Source Types</t> each source.</dd>
<t>Registry Description: The CDNI Telemetry Source Types registr <dt>Interface:</dt><dd>FCI.</dd>
y defines the valid values for the "type" property of the Telemetry Source objec <dt>Encoding:</dt><dd>See <xref target="telemetry-capability-object"
t defined in <xref target="telemetry-source-object"/>.</t> format="default"/>.</dd>
<t>Registration Procedure: The registry follows the Specificatio </dl>
n Required policy as defined in <xref target="RFC8126" />.
The Designated Expert should consider the following guidelines w
hen evaluating registration requests:</t>
<list style="symbols">
<t>The new type definition does not duplicate existing types
.</t>
<t>The review should verify that the telemetry source is app
licable to the CDNI use cases and that the description is clear and unambiguous.
</t>
<t>The registration is applicable for general use and not pr
oprietary.</t>
<t>The "configuration" property has a fully specified object
definition with a description of each defined property.</t>
</list>
<t>The following values will be registered:</t>
<texttable>
<ttcol align="left">
Source Type
</ttcol>
<ttcol align="left">
Specification
</ttcol>
<c>generic</c><c>RFCthis</c>
</texttable>
<section anchor="IANA.cdni.telemetry.generic" title="CDNI Generi
c Telemetry Source Type">
<t><list style="empty">
<t>Purpose: The purpose of this Telemetry Source Type is
to provide a source-agnostic telemetry type that may be used for generic teleme
try source advertisement.</t>
<t>Usage: See <xref target="telemetry-source-object"/>.<
/t>
</list></t>
</section>
</section>
<!-- New CDNI Capacity Limit Types Registry -->
<section anchor="IANA.cdni.capacity.registry" title="&quot;CDNI Capa
city Limit Types&quot; Registry">
<t>
IANA will add the following new registry to the "Content Del
ivery Network Interconnection (CDNI) Parameters" group at https://www.iana.org/a
ssignments/cdni-parameters:
</t>
<t>Registry Name: CDNI Capacity Limit Types</t>
<t>Registry Description: 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"/>.</t>
<t>Registration Procedure: The registry follows the Specificatio
n Required policy as defined in <xref target="RFC8126" />.
The Designated Expert should consider the following guidelines w
hen evaluating registration requests:</t>
<list style="symbols">
<t>The new capacity limit type does not duplicate existing e
ntries.</t>
<t>The submission has a defined purpose. The newly defined c
apacity limit type should be clearly justified in the context of one or more CDN
I use cases.</t>
<t>The description of the capacity limit type is well-docume
nted and unambiguous.</t>
</list>
<t>The following values will be registered:</t>
<texttable>
<ttcol align="left">
Capacity Limit Type
</ttcol>
<ttcol align="left">
Units
</ttcol>
<ttcol align="left">
Specification
</ttcol>
<c>egress</c><c>Bits per second</c><c>RFCthis</c>
<c>requests</c><c>Requests per second</c><c>RFCthis</c>
<c>storage-size</c><c>Total bytes</c><c>RFCthis</c>
<c>storage-objects</c><c>Count</c><c>RFCthis</c>
<c>sessions</c><c>Count</c><c>RFCthis</c>
<c>cache-size</c><c>Total bytes</c><c>RFCthis</c>
</texttable>
<t>Usage: See <xref target="capacity-limit-type"/>.</t>
</section>
</section> </section>
<section anchor="IANA.cdni.fci.capacity.limits.payload.type" numbered="t
rue" toc="default">
<name>CDNI FCI Capacity Limits 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-o
bject" format="default"/>.</dd>
</dl>
<section anchor="Security" title="Security Considerations">
<t>
This specification is in accordance with the CDNI Request Routin
g:
Footprint and Capabilities Semantics. As such, it is subject to
the security and privacy considerations as
defined in Section 7 of
<xref target="RFC8008" />.
</t>
</section> </section>
<section anchor="Acknowledgements" title="Acknowledgements"> </section>
<t> <section anchor="IANA.cdni.telemetry.registry" numbered="true" toc="defaul
The authors would like to express their gratitude to the t">
members of the <name>CDNI Telemetry Source Types Registry</name>
Streaming Video Technology Alliance <t>IANA has added the following new registry within the "Content Deliver
<xref target="SVTA"/> y
Open Caching Working Group for their guidance, contribution, and Network Interconnection (CDNI) Parameters" registry group at
review. <eref target="https://www.iana.org/assignments/cdni-parameters" brackets
</t> ="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 propri
etary.</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>
<!--[rfced] We note that Table 1 includes a description of the
"generic" source type, whereas Table 4 and the IANA registry do
not. Should the description be added to Table 4 and the IANA
registry? In Section 2.1.1.1, should Table 1 be replaced with a
link to Table 4 to avoid duplication?
Current (Section 2.1.1.1):
At the time of this writing, the registry of valid Telemetry Source
Object types is limited to a single type: Generic (see
Section 3.2.1).
Perhaps A:
At the time of this writing, the registry of valid Telemetry Source
Types is limited to a single type: generic (see Table 4 in Section 3.2.1).
or
Perhaps B:
At the time of this writing, the "CDNI Telemetry Source Types" registry
is limited to a single type: generic (see Table 4 in Section 3.2.1).
...
Current (Section 3.2):
+=============+===========+
| Source Type | Reference |
+=============+===========+
| generic | RFC 9808 |
+=============+===========+
Table 4
Perhaps:
+=============+=======================================+===========+
| Source Type | Description | Reference |
+=============+=======================================+===========+
| generic | An object that allows for | RFC 9808 |
| | advertisement of generic data sources | |
+=============+=======================================+===========+
Table 4
-->
<table align="center">
<thead>
<tr>
<th align="left">Source Type</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">generic</td>
<td align="left">RFC 9808</td>
</tr>
</tbody>
</table>
<section anchor="IANA.cdni.telemetry.generic" numbered="true" toc="defau
lt">
<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>
</middle> </section>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.8008"?>
<?rfc include="reference.RFC.8126"?>
<?rfc include="reference.RFC.8174"?>
</references>
<references title="Informative References"> <section anchor="IANA.cdni.capacity.registry" numbered="true" toc="default
<?rfc include="reference.RFC.8006"?> ">
<?rfc include="reference.RFC.6707"?> <name>CDNI Capacity Limit Types Registry</name>
<reference anchor="SVTA" target="https://www.svta.org"> <t>IANA has added the following new registry within the "Content Deliver
<front> y
<title> Network Interconnection (CDNI) Parameters" registry group at
Streaming Video Technology Alliance Home Page <eref target="https://www.iana.org/assignments/cdni-parameters" brackets
</title> ="angle"/>:</t>
<author />
<date /> <dl spacing="normal" newline="false">
</front> <dt>Registry Name:</dt><dd>CDNI Capacity Limit Types</dd>
</reference> <dt>Registry Description:</dt><dd>The "CDNI Capacity Limit Types"
<reference anchor="OCWG" target="https://opencaching.svta.org/"> registry defines the valid values of the "limit-type" property of a
<front> CapacityLimit object defined in <xref target="capacity-limit-object"
<title> 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 an
d 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="defaul
t"/>.</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.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
008.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
006.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
707.xml"/>
<reference anchor="SVTA" target="https://www.svta.org">
<front>
<title>Streaming Video Technology Alliance Home Page</title>
<author/>
<date/>
</front>
</reference>
<!-- [rfced] We note that the following reference entries are not
cited anywhere in the document. These entries will be removed
prior to publication, unless you would like to let us know where
they may be added in the text.
[OC-CII] Ryan, A., Ed., Rosenblum, B., Goldstein, G., Roskin, R.,
and G. Bichot, "Open Caching Capacity Insights -
Functional Specification (Placeholder before
publication)", <https://www.svta.org/document/open-
caching-capacity-interface/>.
[OC-RR] Finkelman, O., Ed., Hofmann, J., Klein, E., Mishra, S.,
Ma, K., Sahar, D., and B. Zurat, "Open Caching Request
Routing - Functional Specification", Version 1.1, 4
October 2019, <https://www.svta.org/product/open-cache-
request-routing-functional-specification/>.
[OCWG] "Open Caching Home Page", <https://opencaching.svta.org/>.
-->
<!-- [OCWG] Not referenced in the text
<reference anchor="OCWG" target="https://opencaching.svta.org/">
<front>
<title>
Open Caching Home Page Open Caching Home Page
</title> </title>
<author /> <author/>
<date /> <date/>
</front> </front>
</reference> </reference>
<reference anchor="OC-CII" target="https://www.svta.org/document/ope -->
n-caching-capacity-interface/">
<front> <!-- [OC-CII] Not referenced in the text
<title> <reference anchor="OC-CII" target="https://www.svta.org/document/open-ca
ching-capacity-interface/">
<front>
<title>
Open Caching Capacity Insights - Functional Specificatio n (Placeholder before publication) Open Caching Capacity Insights - Functional Specificatio n (Placeholder before publication)
</title> </title>
<author initials="A." surname="Ryan" fullname="Andrew Ryan" <author initials="A." surname="Ryan" fullname="Andrew Ryan" role="ed
role="editor"> itor">
<organization> <organization>
Limelight Networks Limelight Networks
</organization> </organization>
</author> </author>
<author initials="B." surname="Rosenblum" fullname="Ben Rose <author initials="B." surname="Rosenblum" fullname="Ben Rosemblum">
mblum"> <organization>
<organization>
Vecima Vecima
</organization> </organization>
</author> </author>
<author initials="G." surname="Goldstein" fullname="Glenn Go <author initials="G." surname="Goldstein" fullname="Glenn Goldstein"
ldstein"> >
<organization> <organization>
Lumen Technologies Lumen Technologies
</organization> </organization>
</author> </author>
<author initials="R." surname="Roskin" fullname="Rob Roskin" <author initials="R." surname="Roskin" fullname="Rob Roskin">
> <organization>
<organization>
Lumen Technologies Lumen Technologies
</organization> </organization>
</author> </author>
<author initials="G." surname="Bichot" fullname="Guillaume B <author initials="G." surname="Bichot" fullname="Guillaume Bichot">
ichot"> <organization>
<organization>
Broadpeak Broadpeak
</organization> </organization>
</author> </author>
<date /> <date/>
</front> </front>
</reference> </reference>
<reference anchor="OC-RR" target="https://www.svta.org/product/open- -->
cache-request-routing-functional-specification/">
<front> <!-- [OC-RR] Not referenced in the text
<title> <reference anchor="OC-RR" target="https://www.svta.org/product/open-cach
e-request-routing-functional-specification/">
<front>
<title>
Open Caching Request Routing - Functional Specification Open Caching Request Routing - Functional Specification
</title> </title>
<author initials="O." surname="Finkelman" fullname="Ori Fink <author initials="O." surname="Finkelman" fullname="Ori Finkelman" r
elman" role="editor"> ole="editor">
<organization> <organization>
Qwilt Qwilt
</organization> </organization>
</author> </author>
<author initials="J." surname="Hofmann" fullname="Jason Hofm <author initials="J." surname="Hofmann" fullname="Jason Hofmann">
ann"> <organization>
<organization>
Limelight Networks Limelight Networks
</organization> </organization>
</author> </author>
<author initials="E." surname="Klein" fullname="Eric Klein"> <author initials="E." surname="Klein" fullname="Eric Klein">
<organization> <organization>
Disney Streaming Services Disney Streaming Services
</organization> </organization>
</author> </author>
<author initials="S." surname="Mishra" fullname="Sanjay Mish <author initials="S." surname="Mishra" fullname="Sanjay Mishra">
ra"> <organization>
<organization>
Verizon Verizon
</organization> </organization>
</author> </author>
<author initials="K." surname="Ma" fullname="Kevin J. Ma"> <author initials="K." surname="Ma" fullname="Kevin J. Ma">
<organization> <organization>
Disney Streaming Services Disney Streaming Services
</organization> </organization>
</author> </author>
<author initials="D." surname="Sahar" fullname="Dan Sahar"> <author initials="D." surname="Sahar" fullname="Dan Sahar">
<organization> <organization>
Qwilt Qwilt
</organization> </organization>
</author> </author>
<author initials="B." surname="Zurat" fullname="Bill Zurat"> <author initials="B." surname="Zurat" fullname="Bill Zurat">
<organization> <organization>
Disney Streaming Services Disney Streaming Services
</organization> </organization>
</author> </author>
<date day="4" month="October" year="2019" /> <date day="4" month="October" year="2019"/>
</front> </front>
<seriesInfo name="Version" value="1.1" /> <seriesInfo name="Version" value="1.1"/>
</reference> </reference>
</references> -->
</back> </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>
<!-- [rfced] Terminology
a) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.
capability object type
Capability Objects
capacity limit-types
Capacity Limits
CDNI Capacity Limit Types
CapacityLimit Object
CapacityLimit object
CapacityLimits Capability Object
FCI capability
FCI.Capability
FCI.Capabilities
limit-type
limit type
Limit Type
Payload types
Payload Types
Telemetry Capability object
Telemetry Capability Object
Telemetry Source
telemetry source
Telemetry sources
Telemetry Source Type
telemetry source type
Telemetry Source Metric Object
Telemetry Source Metric objects
Telemetry Source Object
Telemetry Source object
b) Should the payload types in the following titles be updated to
match the payload types listed in Table 3?
Original:
3.1.1. CDNI FCI Telemetry Payload Type
3.1.2. CDNI FCI Capacity Limits Payload Type
Perhaps:
3.1.1. CDNI FCI.Telemetry Payload Type
3.1.2. CDNI FCI.CapacityLimits Payload Type
-->
<!--[rfced] FYI - We updated the following expansions to the form on
the right for consistency within this document and/or the RFC
Series. Please let us know of any objections.
Content Delivery Networks Interconnection (CDNI) ->
Content Delivery Network Interconnection (CDNI)
Footprints & Capabilities Advertisement Interface (FCI) ->
Footprint & Capabilities Advertisement interface (FCI)
Time To Live (TTL) -> Time to Live (TTL)
-->
<!-- [rfced] Please consider whether the "type" attribute of any sourcecode
element should be set.
The current list of preferred values for "type" is available at
<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
If the current list does not contain an applicable type, feel free to
suggest additions for consideration. Note that it is also acceptable
to leave the "type" attribute not set.
-->
<!-- [rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside)
.
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</rfc> </rfc>
 End of changes. 61 change blocks. 
755 lines changed or deleted 1038 lines changed or added

This html diff was produced by rfcdiff 1.48.