idnits 2.17.1 draft-ryan-cdni-capacity-insights-extensions-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC8008, but the abstract doesn't seem to directly say this. It does mention RFC8008 though, so this could be OK. -- The draft header indicates that this document updates RFC8006, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (3 March 2022) is 777 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Ryan 3 Internet-Draft Disney Streaming 4 Updates: 8006, 8008 (if approved) B. Rosenblum 5 Intended status: Standards Track Vecima 6 Expires: 4 September 2022 N. Sopher 7 Qwilt 8 3 March 2022 10 CDNI Capacity Capability Advertisment Extensions 11 draft-ryan-cdni-capacity-insights-extensions-02 13 Abstract 15 Open Caching architecture is a use case of Content Delivery Networks 16 Interconnection (CDNI) in which the commercial Content Delivery 17 Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer 18 serves as the downstream CDN (dCDN). This document supplements to 19 the CDNI Capability Objects defined in RFC 8008 the defined 20 capability objects structure and interface for advertisments and 21 managment of a downstream CDN capacity. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 4 September 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 1.3. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. CDNI Additonal Capability Objects . . . . . . . . . . . . . . 4 61 2.1. Telemetry Capability Object . . . . . . . . . . . . . . . 5 62 2.1.1. Telemetry Source Object . . . . . . . . . . . . . . . 6 63 2.1.1.1. Telemetry Source Types . . . . . . . . . . . . . 7 64 2.1.1.2. Telemetry Source Metric Object . . . . . . . . . 7 65 2.1.2. Telemetry Capability Object Serialization . . . . . . 8 66 2.2. CapacityLimits Capability Object . . . . . . . . . . . . 9 67 2.2.1. Capacity Limit Object . . . . . . . . . . . . . . . . 9 68 2.2.1.1. Capacity Limit Types . . . . . . . . . . . . . . 11 69 2.2.1.2. Capacity Limit Telemetry Source Object . . . . . 11 70 2.2.1.3. Capacity Limit Scope Object . . . . . . . . . . . 12 71 2.2.2. Capacity Limit Object Serialization . . . . . . . . . 13 72 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 3.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 14 74 3.1.1. CDNI FCI Telemetry Payload Type . . . . . . . . . . . 15 75 3.1.2. CDNI FCI Capacity Limits Payload Type . . . . . . . . 15 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 77 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 78 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 6.1. Normative References . . . . . . . . . . . . . . . . . . 15 80 6.2. Informative References . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 83 1. Introduction 85 The Streaming Video Alliance [SVA] is a global association that works 86 to solve streaming video challenges in an effort to improve end-user 87 experience and adoption. The Open Caching Working Group [OCWG] of 88 the Streaming Video Alliance [SVA] is focused on the delegation of 89 video delivery requests from commerical CDNs to a caching layer at 90 the ISP's network. Open Caching architecture is a specific use case 91 of CDNI where the commercial CDN is the upstream CDN (uCDN) and the 92 ISP caching layer is the downstream CDN (dCDN). While delegating 93 traffic from one CDN to the other, it is important to make sure that 94 an appropriate amount of traffic is delegated. In order to achive 95 that, the SVA Open Caching Capacity Insight Specification [OC-CII] 96 defines a feedback mechanism to inform the delegator how much traffic 97 is appropriate to delegate. The traffic level information provided 98 by that interface will be consumed by entities, such as the Open 99 Caching Request router [OC-RR], to help inform that entity's traffic 100 delegation decisions. This document defines and registers CDNI 101 Payload Types (as defined at section 7.1 of [RFC8006]). These 102 Payload types are used for Capability Objects added to those defined 103 at section 4 of [RFC8008], which are required for the Open Caching 104 Capacity Insights Interface [OC-CII]. 106 For consistency with other CDNI documents this document follows the 107 CDNI convention of uCDN (upstream CDN) and dCDN (downstream CDN) to 108 represent the commercial CDN and ISP caching layer respectively. 110 This document registers two CDNI Payload Types (section 7.1 of 111 [RFC8006]) for the defined capability objects: 113 * Telemetry Payload Type: A payload type for the capability object 114 which defines supported telemetry sources, the metrics made 115 available by that source, and corresponding configuration 116 appropriate to the type of the source (host, port, protocol, 117 etc..). 119 * CapacityLimits Payload Type: a payload type for the capability 120 object which defines Capacity Limits based on a set of defined 121 limit types and a mapping from those limits to corresponding 122 telemetry sources for supporting real-time metrics. 124 1.1. Terminology 126 The following terms are used throughout this document: 128 * CDN - Content Delivery Network 130 Additionally, this document reuses the terminology defined in 131 [RFC6707], [RFC7336], [RFC8006], [RFC8007], [RFC8008], and [RFC8804]. 132 Specifically, we use the following CDNI acronyms: 134 * uCDN, dCDN - Upstream CDN and Downstream CDN respectively (see 135 [RFC7336] ) 137 1.2. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 1.3. Objectives 147 In order to enable information exchange between a uCDN and a dCDN 148 about acceptable levels of traffic to delegate, the following process 149 has been defined: 151 In normal operation a uCDN will communicate with a dCDN, via an 152 interface, to collect and understand any limits that a dCDN has set 153 forth for traffic delegation from a uCDN. These limits will come in 154 the form of metrics such as bits per second, requests per second, 155 etc.. These limits can be thought of as Not to Exceed (NTE) limits. 157 The dCDN should provide access to a telemetry source, of near real 158 time metrics, that the uCDN can use to track current usage. The uCDN 159 should compare it's current usage to the limits the dCDN has put 160 forth and adjust traffic delegation decisions accordingly to keep 161 current usage under the specified limits. 163 In summary, the dCDN will provide the uCDN of limits of how much 164 traffic it should delegate towards the dCDN and then also provide a 165 telemetry source that is coupled to the same scope as the limit, so 166 that the uCDN can use to track its current usage against the 167 advertised limit. Having a limit and a corresponding telemetry 168 source for that limit allows for a non ambiguous definition of what a 169 particular limit means for both the uCDN and dCDN. 171 Limits that are communicated from the dCDN to the uCDN should be 172 considered valid based on the TTL of the response. The TTL of the 173 response will be provided by the transport mechanism for the response 174 i.e. an HTTP Cache-Control header. The intention is that the limits 175 would have a long lived TTL and would represent a reasonable peak 176 utilization limit that the uCDN should target. 178 In the event that a dCDN needs to inform a uCDN of an update to a 179 previously communicated limit, the dCDN SHOULD be able to leverage a 180 uCDN callback endpoint to inform the uCDN of adjusted limits. The 181 most common use case for this would be related to dCDN infrastructure 182 issues which reduced the amount of capacity previously advertised as 183 being available. 185 2. CDNI Additonal Capability Objects 187 Section 5 of [RFC8008] describes the FCI Capability Advertisement 188 Object, which contains a CDNI Capability Object as well as the 189 capability object type (a CDNI Paylod Type). The section also 190 defines the Capability Objects per such type. Below we define two 191 additional Capability Objects. 193 Note: In the following sections, the term "mandatory-to-specify" is 194 used to convey which properties MUST be included when serializing a 195 given capability object. When mandatory-to-specify is defined as 196 "Yes" for an individual property, it means that if the object 197 containing that property is included in an FCI message, then the 198 mandatory-to-specify property MUST also be included. 200 2.1. Telemetry Capability Object 202 The Telemetry Capability Object is used to define a list of telemetry 203 sources made available by the dCDN to the uCDN. In this document, 204 Telemetry data is being defined as near real time aggregated metics 205 of dCDN utilization, such as bits per second egress, and should be 206 specific to the uCDN and dCDN traffic delegation relationship. 207 Telemetry data is uniqiely defined by a source id, a metrics name, 208 along with the footprints that are associated with an FCI.Capability 209 advertisement. When defining a Capacity Limit, the meaning of a 210 limit might be considered ambiguous if the uCDN and dCDN are defining 211 current usage via different data sources. Having the dCDN provide a 212 data source defining usage that both itself and the uCDN reference, 213 allows a non ambiguous metric to use when determing current usage and 214 how that compares to a limit Telemetry data is not only an important 215 component for making informed traffic delegation decisions but also 216 for providing visiblity to traffic that has been delegated back 217 through to upstream providers. In situations where there are mutiple 218 CDNi delegations, a uCDN will need to incorporate the usage 219 information from any dCDN's it delegated to when itself is asked to 220 provide usage information otherwise, the traffic may seem unaccounted 221 for. An example of this situation is when a Content Provider 222 delegates traffic directly to a CDN, and that CDN decides to further 223 delegate that traffic to a dCDN, if the Content Provider polls the 224 uCDN for traffic usage, if the uCDN does not integrate the Telemetry 225 data of the dCDN it delegated to, any of the traffic the uCDN 226 delegated to it's dCDN would become invisible to the Content 227 Provider. 229 Property: sources 231 Description: Telemetry sources made available to the uCDN. 233 Type: A JSON array of Telemetry Source objects (see 234 Section 2.1.1). 236 Mandatory-to-Specify: Yes. 238 2.1.1. Telemetry Source Object 240 The Telemetry Source Object is built of an associated type, a list of 241 exposed metrics, and type-specific configuration data. 243 Property: id 245 Description: A unique identifier of a telemetry source. 247 Type: String. 249 Mandatory-to-Specify: Yes. 251 Property: type 253 Description: A valid telemetry source type. See 254 Section 2.1.1.1. 256 Type: String. 258 Mandatory-to-Specify: Yes. 260 Property: metrics 262 Description: The metrics exposed by this source. 264 Type: A JSON array of Telemetry Source Metric objects (see 265 Section 2.1.1.2). 267 Mandatory-to-Specify: Yes. 269 Property: configuration 271 Description: a source-specific representation of the Telemetry 272 source configuration. For the generic source type, this 273 configuration format is defined out-of-band. For other types, 274 the configuration format will be specified in a yet to be 275 defined Telemetry Interface specification. The goal of this 276 element is to allow for forward compatability with a formal 277 Telemetry interface. 279 Type: A JSON object: TBD 281 Mandatory-to-Specify: No. 283 2.1.1.1. Telemetry Source Types 285 Below are the listed valid telemetry source types. At the time of 286 this draft, the type registry is limit to a single type of Generic. 287 The intention of this type registry is to allow for future extension 288 to reference a yet to be drafted specification for a CDNI Telemetry 289 interface, which would standardize the definition, format,etc of 290 Telemetry data between participants of a CDNI workflow. 292 +=============+======================================+ 293 | Source Type | Description | 294 +=============+======================================+ 295 | generic | An object which allows for | 296 | | advertisement of generic datasources | 297 +-------------+--------------------------------------+ 299 Table 1 301 2.1.1.2. Telemetry Source Metric Object 303 The Telemetry Source Metric Object describe the metric to be exposed. 305 Property: name 307 Description: An identifier unique within this telemetry source. 309 Type: String. 311 Mandatory-to-Specify: Yes. 313 Property: time-granularity 315 Description: Represents the time frame that the data represents 316 in seconds. I.e. is this a data set over 5 minutes, one hour, 317 etc.. 319 Type: Integer. 321 Mandatory-to-Specify: No. 323 Property: data-percentile 325 Description: The percentile calculation the data represents, 326 i.e. 50 percentile would equate to the median over the time- 327 granularity. Lack of a data-percentile will mean that the data 328 is the average over the time representation. 330 Type: Integer. 332 Mandatory-to-Specify: No. 334 Property: latency 336 Description: Time in seconds that the data is behind of real 337 time. This is important to specify to help the uCDN to 338 understand how long it might take to reflect traffic 339 adjustments in the metrics. 341 Type: Integer. 343 Mandatory-to-Specify: No. 345 2.1.2. Telemetry Capability Object Serialization 347 The following shows an example of Telemetry Capability including 2 348 metrics for a source, that is scoped to a footprint. 350 "capabilities": [ 351 { 352 "capability-type": "FCI.Telemetry", 353 "capability-value": { 354 "sources": [ 355 { 356 "id": "capacity_metrics_region1", 357 "type": "generic", 358 "metrics": [ 359 { 360 "name": "egress_5m", 361 "time-granularity": 300, 362 "data-percentile": 50, 363 "latency": 1500 364 }, 365 { 366 "name": "requests_5m", 367 ... 368 } 369 ] 370 } 371 ] 372 }, 373 "footprints": [ 374 375 ] 376 } 377 ] 379 2.2. CapacityLimits Capability Object 381 The Capacity Limits Capability Object enables the dCDN to specify 382 traffic delegation limits to a uCDN within an FCI.Capabilities 383 advertisement. The limits specified by the dCDN will inform the uCDN 384 on how much traffic can be delegated to the dCDN. The limits 385 specified by the dCDN should be considered Not To Exceed (NTE) 386 limits. The limits should be based on near real time telemetry data 387 that the dCDN provides to the uCDN, or in other words, for each limit 388 that is advertised, there should also exist a telemetry source which 389 provides data of current utilization against the particular 390 advertised limit. 392 Property: limits 394 Description: A collection of Capacity Limit objects. 396 Type: A JSON array of CapacityLimit objects (see 397 Section 2.2.1). 399 Mandatory-to-Specify: Yes. 401 2.2.1. Capacity Limit Object 403 A CapacityLimit object is used to represent traffic limits for 404 delegation from the uCDN towards the dCDN. By default the limit 405 object will be scoped to the footprint associated with the FCI 406 capability advertisement encompassing this object. The limit object 407 can contain an optional scoping parameter which will allow 408 specification of a limit for a subset of the encompassing footprint. 409 Limits will be considered using a logical AND, such that a uCDN will 410 need to ensure that all the limits are considered and honored rather 411 than choosing the most specific only. There SHOULD be at least one 412 limit object without an optional scope per capability-value which 413 will define the overall limit for the footprint. 415 Property: scope 417 Description: Defines an additional scope requirement for a 418 limit within the FCI footprint context. This CAN be specified 419 if a dCDN would like to specify a more granular limit than what 420 is currently possible via an FCI footprint alone. An example 421 of using the optional scope would be to specify a limit that 422 should be applied to a specific published hostname within a 423 particular FCI foorprint. A limit object that does not contain 424 this optional scope, should be considered to apply to the 425 entire encompassing footprint associated with the capability 426 advertisement 427 Type: Capacity Limit Scope object (see Section 2.2.1.3). 429 Mandatory-to-Specify: No. 431 Property: limit-type 433 Description: The units of maximum-hard and maximum-soft. 435 Type: String. One of the values listed in Section 2.2.1.1. 437 Mandatory-to-Specify: Yes. 439 Property: id 441 Description: Specifies a unique identifier associated with a 442 limit. The is CAN be used as a relational identifier to a 443 specific Section 2.2.1. 445 Type: String. 447 Mandatory-to-Specify: No. 449 Property: maximum-hard 451 Description: The maximum unit of capacity that is available for 452 use. 454 Type: Integer. 456 Mandatory-to-Specify: Yes. 458 Property: maximum-soft 460 Description: A soft limit at which an upstream should consider 461 deducing traffic to prevent hitting the hard limit. 463 Type: Integer. 465 Mandatory-to-Specify: No. 467 Property: current 469 Description: Specifies the current usage value of the limit. 470 It is not recommended to specify the current usage value inline 471 with the FCI.CapacityLimits advertisements as it will reduce 472 the ability to cache the response. The intended method for 473 providing telemetry data is to reference a Section 2.2.1.2 to 474 poll for the current usage. 476 Type: Integer. 478 Mandatory-to-Specify: No. 480 Property: telemetry-source 482 Description: Mapping of each a particular limit to a specific 483 metric with relevant real-time data provided by a telemetry 484 source. 486 Type: Capacity Limit Telemetry Source object (see 487 Section 2.2.1.2). 489 Mandatory-to-Specify: No. 491 2.2.1.1. Capacity Limit Types 493 Below are listed the valid capacity limit types. Additional limits 494 would need to be specified and extended into this list. The values 495 specified here represent the types that were identified as being the 496 most relevant metrics for the purposes of traffic delegation between 497 CDNs. 499 +=================+=====================+ 500 | Limit Type | Units | 501 +=================+=====================+ 502 | egress | Bits per second | 503 +-----------------+---------------------+ 504 | requests | Requests per second | 505 +-----------------+---------------------+ 506 | storage-size | Total bytes | 507 +-----------------+---------------------+ 508 | storage-objects | Count | 509 +-----------------+---------------------+ 510 | sessions | Count | 511 +-----------------+---------------------+ 512 | cache-size | Total bytes | 513 +-----------------+---------------------+ 515 Table 2 517 2.2.1.2. Capacity Limit Telemetry Source Object 519 The Capacity Limit Telemetry Source Object refers to a specific 520 metric within a Telementry Source. 522 Property: id 523 Description: Reference to the "id" of a telemetry source 524 defined by a Telemetry Capability object. 526 Type: String. 528 Mandatory-to-Specify: Yes. 530 Property: metric 532 Description: Reference to the "name" property of a metric 533 defined within a telemetry source of an FCI.Telemetry 534 Capability object. 536 Type: String. 538 Mandatory-to-Specify: Yes. 540 2.2.1.3. Capacity Limit Scope Object 542 A CapacityLimitScope object is used to define a more granular scope 543 for a limit within the encompassing footprint. The object will 544 define what type of scope is being declared (published host, service 545 ids, etc..) and will then contain an array of items of the type 546 defined (publishedhostA.cdn.com, publishedhostB.cdn.com,..). The 547 scope types are meant to be extendible and reference already 548 established identifiers commonly used in delivery via a CDN. The 549 scope types MUST be mutually understood between the uCDN and dCDN. 551 Property: type 553 Description: Defines the type of scope definition. 555 Type: String. One of the values listed in Section 2.2.1.3.1. 557 Mandatory-to-Specify: Yes. 559 Property: values 561 Description: A collection of values of Section 2.2.1.3.1. 563 Type: A JSON array of strings of (see Section 2.2.1.3.1). 565 Mandatory-to-Specify: Yes. 567 2.2.1.3.1. Capacity Limit Scope Types 569 Below are listed the valid capacity limit types. Additional limits 570 would need to be specified and extended into this list. The values 571 specified here represent the types that were identified as being the 572 most relevant metrics for the purposes of traffic delegation between 573 CDNs. The most recognized value will be the published-host, while 574 the other values listed correspond to identifiers commonly used with 575 commercial CDN providers that either reference a specific 576 configuration or a logical grouping of configurations. 578 +================+===============================+ 579 | Scope Type | Description | 580 +================+===============================+ 581 | published-host | CDN-Domain | 582 +----------------+-------------------------------+ 583 | service-id | an identifier associated with | 584 | | a group of configurations | 585 +----------------+-------------------------------+ 586 | property-id | an identifier associated with | 587 | | a specific configuration | 588 +----------------+-------------------------------+ 590 Table 3 592 2.2.2. Capacity Limit Object Serialization 594 The following shows an example of an FCI.CapacityLimits object. 596 "capabilities":[ 597 { 598 "capability-type":"FCI.CapacityLimits", 599 "capability-value":{ 600 "limits":[ 601 { 602 "id":"capacity_limit_region1", 603 "limit-type":"egress", 604 "maximum-hard":50000000000, 605 "maximum-soft":25000000000, 606 "telemetry-source":{ 607 "id":"capacity_metrics_region1", 608 "metric":"egress_5m" 609 } 610 }, 611 { 612 "id":"capacity_limit_region1", 613 "scope":{ 614 "type":"published-host", 615 "values":[ 616 "serviceA.cdn.example.com" 617 ] 618 }, 619 "limit-type":"egress", 620 "maximum-hard":20000000000, 621 "maximum-soft":10000000000, 622 "telemetry-source":{ 623 "id":"capacity_metrics_region1", 624 "metric":"egress_service2_5m" 625 } 626 }, 627 { 628 "scope":{ 629 "type":"service-id", 630 "Values":[ 631 "abcd4567ef9a" 632 ] 633 }, 634 "limit-type":"egress", 635 "maximum-hard":30000000000, 636 "maximum-soft":15000000000, 637 "current":20000000000, 638 "telemetry-source":{ 639 "id":"capacity_metrics_region3", 640 "metric":"egress_service3_5m" 641 } 642 } 643 ] 644 }, 645 "footprints":[ 646 "" 647 ] 648 } 649 ] 651 3. IANA Considerations 653 3.1. CDNI Payload Types 655 similar to the type definitions described in section 7.1 of [RFC8006] 656 as well as the types described in section 6.1 of [RFC8008]. 658 This document requests the registration of the two additional payload 659 types: 661 +====================+===============+ 662 | Payload Type | Specification | 663 +====================+===============+ 664 | FCI.Telemetry | RFCthis | 665 +--------------------+---------------+ 666 | FCI.CapacityLimits | RFCthis | 667 +--------------------+---------------+ 669 Table 4 671 [RFC Editor: Please replace RFCthis with the published RFC number for 672 this document.] 674 3.1.1. CDNI FCI Telemetry Payload Type 676 Purpose: The purpose of this Payload Type is to list the supported 677 telemetry sources and the metrics made available by each source). 679 Interface: FCI. 681 Encoding: See section Section 2.1. 683 3.1.2. CDNI FCI Capacity Limits Payload Type 685 Purpose: The purpose of this Payload Type is to define Capacity 686 Limits based on a utilization metrics corresponding to telemetry 687 sources provided by the dCDN. 689 Interface: FCI. 691 Encoding: See section Section 2.2. 693 4. Security Considerations 695 This specification is in accordance with the CDNI Request Routing: 696 Footprint and Capabilities Semantics. As such, it is subject to the 697 security and privacy considerations as defined in Section 8 of 698 [RFC8006] and in Section 7 of [RFC8008] respectively. 700 5. Acknowledgements 702 The authors would like to express their gratitude to TBD for TBD 703 (their guidance / contribution / reviews ...) 705 6. References 707 6.1. Normative References 709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 710 Requirement Levels", BCP 14, RFC 2119, 711 DOI 10.17487/RFC2119, March 1997, 712 . 714 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 715 "Content Delivery Network Interconnection (CDNI) 716 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 717 . 719 [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network 720 Interconnection (CDNI) Control Interface / Triggers", 721 RFC 8007, DOI 10.17487/RFC8007, December 2016, 722 . 724 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 725 R., and K. Ma, "Content Delivery Network Interconnection 726 (CDNI) Request Routing: Footprint and Capabilities 727 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 728 . 730 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 731 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 732 May 2017, . 734 [RFC8804] Finkelman, O. and S. Mishra, "Content Delivery Network 735 Interconnection (CDNI) Request Routing Extensions", 736 RFC 8804, DOI 10.17487/RFC8804, September 2020, 737 . 739 6.2. Informative References 741 [OC-CII] Ryan, A., Ed., Rosenblum, B., Goldstein, G., Roskin, R., 742 and G. Bichot, "Open Caching Capacity Insights - 743 Functional Specification (Placeholder before 744 publication)", 745 . 748 [OC-RR] Finkelman, O., Ed., Hofmann, J., Klein, E., Mishra, S., 749 Ma, K., Sahar, D., and B. Zurat, "Open Caching Request 750 Routing - Functional Specification", Version 1.1, 4 751 October 2019, 752 . 755 [OCWG] "Open Caching Home Page", 756 . 758 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 759 Distribution Network Interconnection (CDNI) Problem 760 Statement", RFC 6707, DOI 10.17487/RFC6707, September 761 2012, . 763 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 764 "Framework for Content Distribution Network 765 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 766 August 2014, . 768 [SVA] "Streaming Video Alliance Home Page", 769 . 771 Authors' Addresses 773 Andrew Ryan 774 Disney Streaming 775 1211 Avenue of the Americas 776 New York 777 , NY 10036 778 United States of America 779 Email: andrew@andrewnryan.com 781 Ben Rosenblum 782 Vecima 783 4375 River Green Pkwy #100 784 Duluth 785 , GA 30096 786 United States of America 787 Email: ben@rosenblum.dev 789 Nir B. Sopher 790 Qwilt 791 6, Ha'harash 792 Hod HaSharon 793 4524079 794 Israel 795 Email: nir@apache.org