idnits 2.17.1 draft-ietf-cdni-footprint-capabilities-semantics-19.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 14, 2016) is 2902 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) == Outdated reference: A later version (-27) exists of draft-ietf-cdni-logging-25 == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-16 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Downref: Normative reference to an Informational RFC: RFC 7336 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CDNI J. Seedorf 3 Internet-Draft NEC 4 Intended status: Standards Track J. Peterson 5 Expires: November 15, 2016 Neustar 6 S. Previdi 7 Cisco 8 R. van Brandenburg 9 TNO 10 K. Ma 11 Ericsson 12 May 14, 2016 14 CDNI Request Routing: Footprint and Capabilities Semantics 15 draft-ietf-cdni-footprint-capabilities-semantics-19 17 Abstract 19 This document captures the semantics of the "Footprint and 20 Capabilities Advertisement" part of the CDNI Request Routing 21 interface, i.e., the desired meaning of "Footprint" and 22 "Capabilities" in the CDNI context, and what the "Footprint and 23 Capabilities Advertisement Interface (FCI)" offers within CDNI. The 24 document also provides guidelines for the CDNI FCI protocol. It 25 further defines a Base Advertisement Object, the necessary registries 26 for capabilities and footprints, and guidelines on how these 27 registries can be extended in the future. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on November 15, 2016. 51 Copyright Notice 53 Copyright (c) 2016 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 3 69 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Design Decisions for Footprint and Capabilities . . . . . . . 5 71 2.1. Advertising Limited Coverage . . . . . . . . . . . . . . 5 72 2.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 6 73 2.3. Advertisement versus Queries . . . . . . . . . . . . . . 7 74 2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7 75 3. Focusing on Capabilities with Footprint Restrictions . . . . 8 76 4. Footprint and Capabilities Extension . . . . . . . . . . . . 8 77 5. Capability Advertisement Object . . . . . . . . . . . . . . . 10 78 5.1. Base Advertisement Object . . . . . . . . . . . . . . . . 10 79 5.2. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 11 80 5.3. Delivery Protocol Capability Object . . . . . . . . . . . 11 81 5.3.1. Delivery Protocol Capability Object Serialization . . 12 82 5.4. Acquisition Protocol Capability Object . . . . . . . . . 12 83 5.4.1. Acquisition Protocol Capability Object Serialization 13 84 5.5. Redirection Mode Capability Object . . . . . . . . . . . 13 85 5.5.1. Redirection Mode Capability Object Serialization . . 13 86 5.6. CDNI Logging Capability Object . . . . . . . . . . . . . 14 87 5.6.1. CDNI Logging Capability Object Serialization . . . . 15 88 5.7. CDNI Metadata Capability Object . . . . . . . . . . . . . 15 89 5.7.1. CDNI Metadata Capability Object Serialization . . . . 16 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 91 6.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 17 92 6.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 17 93 6.1.2. CDNI FCI AcquisitionProtocol Payload Type . . . . . . 18 94 6.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 18 95 6.1.4. CDNI FCI Logging Payload Type . . . . . . . . . . . . 18 96 6.1.5. CDNI FCI Metadata Payload Type . . . . . . . . . . . 18 98 6.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 18 99 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 100 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 101 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 102 8.2. Informative References . . . . . . . . . . . . . . . . . 20 103 Appendix A. Main Use Case to Consider . . . . . . . . . . . . . 21 104 Appendix B. Semantics for Footprint Advertisement . . . . . . . 22 105 Appendix C. Semantics for Capabilities Advertisement . . . . . . 24 106 Appendix D. Acknowledgment . . . . . . . . . . . . . . . . . . . 25 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 109 1. Introduction and Scope 111 The CDNI working group is working on a set of protocols to enable the 112 interconnection of multiple CDNs. This CDN interconnection (CDNI) 113 can serve multiple purposes, as discussed in [RFC6770], for instance, 114 to extend the reach of a given CDN to areas in the network which are 115 not covered by this particular CDN. 117 The goal of this document is to achieve a clear understanding about 118 the semantics associated with the CDNI Request Routing Footprint & 119 Capabilities Advertisement Interface (from now on referred to as 120 FCI), in particular the type of information a downstream CDN (dCDN) 121 'advertises' regarding its footprint and capabilities. To narrow 122 down undecided aspects of these semantics, this document tries to 123 establish a common understanding of what the FCI needs to offer and 124 accomplish in the context of CDNI. 126 It is explicitly outside the scope of this document to decide on 127 specific protocols to use for the FCI. However, guidelines for such 128 FCI protocols are provided. 130 General assumptions in this document: 132 o The CDNs participating in the interconnected CDN have already 133 performed a boot strap process, i.e., they have connected to each 134 other, either directly or indirectly, and can exchange information 135 amongst each other. 137 o The upstream CDN (uCDN) receives footprint and/or capability 138 advertisements from a set of dCDNs. Footprint advertisement and 139 capability advertisement need not use the same underlying 140 protocol. 142 o The uCDN receives the initial request-routing request from the 143 endpoint requesting the resource. 145 The CDNI Problem Statement [RFC6707] describes the Request Routing 146 Interface as: "[enabling] a Request Routing function in a uCDN to 147 query a Request Routing function in a dCDN to determine if the dCDN 148 is able (and willing) to accept the delegated Content Request". In 149 addition, RFC6707 says "the CDNI Request Routing interface is also 150 expected to enable a dCDN to provide to the uCDN (static or dynamic) 151 information (e.g., resources, footprint, load) to facilitate 152 selection of the dCDN by the uCDN request routing system when 153 processing subsequent content requests from User Agents". It thus 154 considers "resources" and "load" as capabilities to be advertised by 155 the dCDN. 157 The range of different footprint definitions and possible 158 capabilities is very broad. Attempting to define a comprehensive 159 advertisement solution quickly becomes intractable. The CDNI 160 requirements draft [RFC7337] lists the specific requirements for the 161 CDNI Footprint & Capabilities Advertisement Interface in order to 162 disambiguate footprints and capabilities with respect to CDNI. This 163 document defines a common understanding of what the terms 'footprint' 164 and 'capabilities' mean in the context of CDNI, and details the 165 semantics of the footprint advertisement mechanism and the capability 166 advertisement mechanism. 168 1.1. Terminology 170 This document reuses the terminology defined in [RFC6707]. 172 Additionally, the following terms are used throughout this document 173 and are defined as follows: 175 o Footprint: a description of a CDN's coverage area, i.e., the area 176 from which client requests may originate for, and to which the CDN 177 is willing to deliver, content. Note: There are many ways to 178 describe a footprint, for example, by address range (e.g., IPv4/ 179 IPv6 CIDR), by network ID (e.g., ASN), by nation boundaries (e.g., 180 country code), by GPS coordinates, etc. This document does not 181 define or endorse the quality or suitability of any particular 182 footprint description method; this document only defines a method 183 for transporting known footprint descriptions in Footprint and 184 Capabilities Advertisement messages. 186 o Capability: a feature of a dCDN, upon which a uCDN relies on the 187 dCDN supporting, when making delegation decisions. Support for a 188 given feature can change over time and can be restricted to a 189 limited portion of a dCDN's footprint. Note: There are many 190 possible dCDN features that could be of interest to a uCDN. This 191 document does not presume to define them all; this document 192 describes a scheme for defining new capabilities and how to 193 transport them in Footprint and Capabilities Advertisement 194 messages. 196 2. Design Decisions for Footprint and Capabilities 198 A large part of the difficulty in discussing the FCI lies in 199 understanding what exactly is meant when trying to define footprint 200 in terms of "coverage" or "reachability." While the operators of 201 CDNs pick strategic locations to situate surrogates, a surrogate with 202 a public IPv4 address is reachable by any endpoint on the Internet 203 unless some policy enforcement precludes the use of the surrogate. 205 Some CDNs aspire to cover the entire world; we refer to these as 206 global CDNs. The footprint advertised by such a CDN in the CDNI 207 environment would, from a coverage or reachability perspective, 208 presumably cover all prefixes. Potentially more interesting for CDNI 209 use cases, however, are CDNs that claim a more limited coverage, but 210 seek to interconnect with other CDNs in order to create a single CDN 211 fabric which shares resources. 213 Furthermore, not all capabilities need to be footprint restricted. 214 Depending upon the use case, the optimal semantics of "footprints 215 with capability attributes" vs. "capabilities with footprint 216 restrictions" are not clear. 218 The key to understanding the semantics of footprint and capability 219 advertisement lies in understanding why a dCDN would advertise a 220 limited coverage area, and how a uCDN would use such advertisements 221 to decide among one of several dCDNs. The following section will 222 discuss some of the trade-offs and design decisions that need to be 223 decided upon for the CDNI FCI. 225 2.1. Advertising Limited Coverage 227 The basic use case that would motivate a dCDN to advertise a limited 228 coverage is that the CDN was built to cover only a particular portion 229 of the Internet. For example, an ISP could purpose-build a CDN to 230 serve only their own customers by situating surrogates in close 231 topological proximity to high concentrations of their subscribers. 232 The ISP knows the prefixes it has allocated to end users and thus can 233 easily construct a list of prefixes that its surrogates were 234 positioned to serve. 236 When such a purpose-built CDN interconnects with other CDNs and 237 advertises its footprint to a uCDN, however, the original intended 238 coverage of the CDN might not represent its actual value to the 239 interconnection of CDNs. Consider an ISP-A and ISP-B that both field 240 their own CDNs, which they interconnect via CDNI. A given user E, 241 who is a customer of ISP-B, might happen to be topologically closer 242 to a surrogate fielded by ISP-A, if E happens to live in a region 243 where ISP-B has few customers and ISP-A has many. In this case, is 244 it ISP-A's CDN that "covers" E? If ISP-B's CDN has a failure 245 condition, is it up to the uCDN to understand that ISP-A's surrogates 246 are potentially available as back-ups - and if so, how does ISP-A 247 advertise itself as a "standby" for E? What about the case where 248 CDNs advertising to the same uCDN express overlapping coverage (for 249 example, mixing global and limited CDNs)? 251 The answers to these questions greatly depend on how much information 252 the uCDN wants to use to make a selection of a dCDN. If a uCDN has 253 three dCDNs to choose from that "cover" the IP address of user E, 254 obviously the uCDN might be interested to know how optimal the 255 coverage is from each of the dCDNs - coverage need not be binary, 256 either provided or not provided. dCDNs could advertise a coverage 257 "score," for example, and provided that they all reported scores 258 fairly on the same scale, uCDNs could use that to make their 259 topological optimality decision. Alternately, dCDNs could advertise 260 the IP addresses of their surrogates rather than prefix "coverage," 261 and let the uCDN decide for itself (based on its own topological 262 intelligence) which dCDN has better resources to serve a given user. 264 In summary, the semantics of advertising footprint depend on whether 265 such qualitative metrics for expressing footprint (such as the 266 coverage 'score' mentioned above) are included as part of the CDNI 267 FCI, or if the focus is just on 'binary' footprint. 269 2.2. Capabilities and Dynamic Data 271 In cases where the apparent footprints of dCDNs overlap, uCDNs might 272 also want to rely on other factors to evaluate the respective merits 273 of dCDNs. These include facts related to the surrogates themselves, 274 to the network where the surrogate is deployed, to the nature of the 275 resource sought, and to the administrative policies of the respective 276 networks. 278 In the absence of network-layer impediments to reaching surrogates, 279 the choice to limit coverage is necessarily an administrative policy. 280 Much policy needs to be agreed upon before CDNs can interconnect, 281 including questions of membership, compensation, volumes, and so on. 282 A uCDN certainly will factor these sorts of considerations into its 283 decision to select a dCDN, but there is probably little need for 284 dCDNs to actually advertise them through an interface - they will be 285 settled out-of-band as a precondition for interconnection. 287 Other facts about the dCDN would be expressed through the interface 288 to the uCDN. Some capabilities of a dCDN are static, and some are 289 highly dynamic. Expressing the total storage built into its 290 surrogates, for example, changes relatively rarely, whereas the 291 amount of storage in use at any given moment is highly volatile. 292 Network bandwidth similarly could be expressed as either total 293 bandwidth available to a surrogate, or based on the current state of 294 the network. A surrogate can at one moment lack a particular 295 resource in storage, but have it the next. 297 The semantics of the capabilities interface will depend on how much 298 of the dCDN state needs to be pushed to the uCDN and qualitatively 299 how often that information needs to be updated. 301 2.3. Advertisement versus Queries 303 In a CDNI environment, each dCDN shares some of its state with the 304 uCDN. The uCDN uses this information to build a unified picture of 305 all of the dCDNs available to it. In architectures that share 306 detailed capability information, the uCDN could perform the entire 307 request-routing operation down to selecting a particular surrogate in 308 the dCDN. However, when the uCDN needs to deal with many potential 309 dCDNs, this approach does not scale, especially for dCDNs with 310 thousands or tens of thousands of surrogates; the volume of updates 311 to footprint and capability becomes onerous. 313 Were the volume of FCI updates from dCDNs to exceed the volume of 314 requests to the uCDN, it might make more sense for the uCDN to query 315 dCDNs upon receiving requests (as is the case in the recursive 316 redirection mode described in [RFC7336]), instead of receiving 317 advertisements and tracking the state of dCDNs. The advantage of 318 querying dCDNs would be that much of the dynamic data that dCDNs 319 cannot share with the uCDN would now be factored into the uCDN's 320 decision. dCDNs need not replicate any state to the uCDN - uCDNs 321 could effectively operate in a stateless mode. 323 The semantics of both footprint and capability advertisement depend 324 on the service model here: are there cases where a synchronous query/ 325 response model would work better for the uCDN decision than a state 326 replication model? 328 2.4. Avoiding or Handling 'cheating' dCDNs 330 In a situation where more than one dCDN is willing to serve a given 331 end user request, it might be attractive for a dCDN to 'cheat' in the 332 sense that the dCDN provides inaccurate information to the uCDN in 333 order to convince the uCDN to select it over 'competing' dCDNs. It 334 could therefore be desirable to take away the incentive for dCDNs to 335 cheat (in information advertised) as much as possible. One option is 336 to make the information the dCDN advertises somehow verifiable for 337 the uCDN. On the other hand, a cheating dCDN might be avoided or 338 handled by the fact that there will be strong contractual agreements 339 between a uCDN and a dCDN, so that a dCDN would risk severe penalties 340 or legal consequences when caught cheating. 342 Overall, the information a dCDN advertises (in the long run) needs to 343 be somehow qualitatively verifiable by the uCDN, though possibly 344 through non-real-time out-of-band audits. It is probably an overly 345 strict requirement to mandate that such verification be possible 346 "immediately", i.e., during the request routing process itself. If 347 the uCDN can detect a cheating dCDN at a later stage, it might 348 suffice for the uCDN to "de-incentivize" cheating because it would 349 negatively affect the long-term business relationship with a 350 particular dCDN. 352 3. Focusing on Capabilities with Footprint Restrictions 354 Given the design considerations listed in the previous section, it 355 seems reasonable to assume that in most cases it is the uCDN that 356 makes the decision on selecting a certain dCDN for request routing 357 based on information the uCDN has received from this particular dCDN. 358 It can be assumed that 'cheating' CDNs will be dealt with via means 359 outside the scope of CDNI and that the information advertised between 360 CDNs is accurate. In addition, excluding the use of qualitative 361 information (e.g., surrogate proximity, delivery latency, surrogate 362 load) to predict the quality of delivery would further simplify the 363 use case allowing it to better focus on the basic functionality of 364 the FCI. 366 Further understanding that in most cases contractual agreements will 367 define the basic coverage used in delegation decisions, the primary 368 focus of FCI is on providing updates to the basic capabilities and 369 coverage by the dCDNs. As such, FCI has choosen the semantics of 370 "capabilities with footprint restrictions". 372 4. Footprint and Capabilities Extension 374 Other optional "coverage/reachability" types of footprint or 375 "resource" types of footprint may be defined by future 376 specifications. To facilitate this, a clear process for specifying 377 optional footprint types in an IANA registry is specified in the CDNI 378 Metadata Footprint Types registry (defined in the CDNI Metadata 379 Interface document [I-D.ietf-cdni-metadata]). 381 This document also registers CDNI Payload Types [RFC7736] for the 382 initial capability types (see Section 6): 384 o Delivery Protocol (for delivering content to the end user) 385 o Acquisition Protocol (for acquiring content from the uCDN or 386 origin server) 388 o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as 389 discussed in [RFC7336]) 391 o CDNI Logging (i.e., supported logging fields) 393 o CDNI Metadata (i.e., supported Generic Metadata types) 395 Each payload type is prefaced with "FCI.". Updates to capability 396 objects MUST indicate the version of the capability object in a newly 397 registered payload type, e.g., by appending ".v2". Each capability 398 type MAY have a list of valid values. Future specifications which 399 define a given capability MUST define any necessary registries (and 400 the rules for adding new entries to the registry) for the values 401 advertised for a given capability type. 403 The "CDNI Logging record-types" registry [I-D.ietf-cdni-logging] 404 defines all known record types, including mandatory-to-implement 405 record-types Advertising support for mandatory-to-implement record- 406 types would be redundant. CDNs SHOULD NOT advertise support for 407 mandatory-to-implement record-types. 409 The "CDNI Logging Fields Names" registry [I-D.ietf-cdni-logging] 410 defines all known logging fields. Logging fields may be reused by 411 different record-types and be mandatory-to-implement in some record- 412 types, but optional in other record-types. CDNs MUST advertise 413 support for optional logging fields within the context of a specific 414 record-type. CDNs SHOULD NOT advertise support for mandatory-to- 415 implement logging fields, for a given record-type. The following 416 logging fields are defined as optional for the "cdni_http_request_v1" 417 record-type in the CDNI Logging Interface document 418 [I-D.ietf-cdni-logging]: 420 o s-ccid 422 o s-sid 424 The CDNI Metadata Interface document [I-D.ietf-cdni-metadata] 425 requires that CDNs be able to parse all the defined metadata objects, 426 but does not require dCDNs to support enforcement of non-structural 427 GenericMetadata objects. Advertising support for mandatory-to- 428 enforce GenericMetadata types MUST be supported. Advertising support 429 for non-mandatory-to-enforce GenericMetadata types SHOULD be 430 supported. Advertisement of non-mandatory-to-enforce GenericMetadata 431 MAY be necessary, e.g., to signal temporary outages and subsequent 432 recovery. It is expected that structural metadata will be supported 433 at all times. 435 The notion of optional types of footprint and capabilities implies 436 that certain implementations might not support all kinds of footprint 437 and capabilities. Therefore, any FCI solution protocol MUST define 438 how the support for optional types of footprint/capabilities will be 439 negotiated between a uCDN and a dCDN that use the particular FCI 440 protocol. In particular, any FCI solution protocol MUST specify how 441 to handle failure cases or non-supported types of footprint/ 442 capabilities. 444 In general, a uCDN MAY ignore capabilities or types of footprints it 445 does not understand; in this case it only selects a suitable dCDN 446 based on the types of capabilities and footprint it understands. 447 Similarly, if a dCDN does not use an optional capability or footprint 448 which is, however, supported by a uCDN, this causes no problem for 449 the FCI functionality because the uCDN decides on the remaining 450 capabilities/footprint information that is being conveyed by the 451 dCDN. 453 5. Capability Advertisement Object 455 To support extensibility, the FCI defines a generic base object 456 (similar to the CDNI Metadata interface GenericMetadata object) 457 [I-D.ietf-cdni-metadata] to facilitate a uniform set of mandatory 458 parsing requirements for all future FCI objects. 460 Future object definitions (e.g. regarding CDNI Metadata or Logging) 461 will build off the base object defined here, but will be specified in 462 separate documents. 464 Note: In the following sections, the term "mandatory-to-specify" is 465 used to convey which properties MUST be included when serializing a 466 given capability object. When mandatory-to-specify is defined as 467 "Yes" for an individual property, it means that if the object 468 containing that property is included in an FCI message, then the 469 mandatory-to-specify property MUST also be included. 471 5.1. Base Advertisement Object 473 The FCIBase object is an abstraction for managing individual CDNI 474 capabilities in an opaque manner. 476 Property: capability-type 478 Description: CDNI Capability object type. 480 Type: FCI specific CDNI Payload type (from the CDNI Payload 481 Types registry [RFC7736]) 483 Mandatory-to-Specify: Yes. 485 Property: capability-value 487 Description: CDNI Capability object. 489 Type: Format/Type is defined by the value of capability-type 490 property above. 492 Mandatory-to-Specify: Yes. 494 Property: footprints 496 Description: CDNI Capability Footprint. 498 Type: List of CDNI Footprint objects (as defined in 499 [I-D.ietf-cdni-metadata]). 501 Mandatory-to-Specify: No. 503 5.2. Encoding 505 CDNI FCI objects MUST be encoded using JSON [RFC7159] and MUST also 506 follow the recommendations of I-JSON [RFC7493]. FCI objects are 507 composed of a dictionary of (key,value) pairs where the keys are the 508 property names and the values are the associated property values. 510 The keys of the dictionary are the names of the properties associated 511 with the object and are therefore dependent on the specific object 512 being encoded (i.e., dependent on the CDNI Payload Type of the 513 capability or the CDNI Metadata Footprint Type of the footprint). 514 Likewise, the values associated with each property (dictionary key) 515 are dependent on the specific object being encoded (i.e., dependent 516 on the CDNI Payload Type of the capability or the CDNI Metadata 517 Footprint Type of the footprint). 519 Dictionary keys (properties) in JSON are case sensitive. By 520 convention, any dictionary key (property) defined by this document 521 MUST be lowercase. 523 5.3. Delivery Protocol Capability Object 525 The Delivery Protocol capability object is used to indicate support 526 for one or more of the protocols listed in the CDNI Metadata Protocol 527 Types registry (defined in the CDNI Metadata Interface document 528 [I-D.ietf-cdni-metadata]). 530 Property: delivery-protocols 532 Description: List of supported CDNI Delivery Protocols. 534 Type: List of Protocol Types (from the CDNI Metadata Protocol 535 Types registry [I-D.ietf-cdni-metadata]) 537 Mandatory-to-Specify: Yes. 539 5.3.1. Delivery Protocol Capability Object Serialization 541 The following shows an example of Delivery Protocol Capability Object 542 Serialization, for a CDN that supports only HTTP/1.1 without TLS for 543 content delivery. 545 { 546 "capabilities": [ 547 { 548 "capability-type": "FCI.DeliveryProtocol", 549 "capability-value": { 550 "delivery-protocols": [ 551 "http1.1", 552 ] 553 }, 554 "footprints": [ 555 556 ] 557 } 558 ] 559 } 561 5.4. Acquisition Protocol Capability Object 563 The Acquisition Protocol capability object is used to indicate 564 support for one or more of the protocols listed in the CDNI Metadata 565 Protocol Types registry (defined in the CDNI Metadata Interface 566 document [I-D.ietf-cdni-metadata]). 568 Property: acquisition-protocols 570 Description: List of supported CDNI Acquisition Protocols. 572 Type: List of Protocol Types (from the CDNI Metadata Protocol 573 Types registry [I-D.ietf-cdni-metadata]) 574 Mandatory-to-Specify: Yes. 576 5.4.1. Acquisition Protocol Capability Object Serialization 578 The following shows an example of Acquisition Protocol Capability 579 Object Serialization, for a CDN that supports HTTP/1.1 with or 580 without TLS for content acquisition. 582 { 583 "capabilities": [ 584 { 585 "capability-type": "FCI.AcquisitionProtocol", 586 "capability-value": { 587 "acquisition-protocols": [ 588 "http1.1", 589 "https1.1" 590 ] 591 }, 592 "footprints": [ 593 594 ] 595 } 596 ] 597 } 599 5.5. Redirection Mode Capability Object 601 The Redirection Mode capability object is used to indicate support 602 for one or more of the modes listed in the CDNI Capabilities 603 Redirection Modes registry (see Section 6.2). 605 Property: redirection-modes 607 Description: List of supported CDNI Redirection Modes. 609 Type: List of Redirection Modes (from Section 6.2) 611 Mandatory-to-Specify: Yes. 613 5.5.1. Redirection Mode Capability Object Serialization 615 The following shows an example of Redirection Mode Capability Object 616 Serialization, for a CDN that supports only iterative (but not 617 recursive) redirection with HTTP and DNS. 619 { 620 "capabilities": [ 621 { 622 "capability-type": "FCI.RedirectionMode", 623 "capability-value": { 624 "redirection-modes": [ 625 "DNS-I", 626 "HTTP-I" 627 ] 628 } 629 "footprints": [ 630 631 ] 632 } 633 ] 634 } 636 5.6. CDNI Logging Capability Object 638 The CDNI Logging capability object is used to indicate support for 639 CDNI Logging record-types, as well as CDNI Logging fields which are 640 marked as optional for the specified record-types 641 [I-D.ietf-cdni-logging]. 643 Property: record-type 645 Description: Supported CDNI Logging record-type. 647 Type: String corresponding to an entry from the CDNI Logging 648 record-types registry [I-D.ietf-cdni-logging]) 650 Mandatory-to-Specify: Yes. 652 Property: fields 654 Description: List of supported CDNI Logging fields that are 655 optional for the specified record-type. 657 Type: List of Strings corresponding to entries from the CDNI 658 Logging Field Names registry [I-D.ietf-cdni-logging]. 660 Mandatory-to-Specify: No. Default is that all optional fields 661 are supported. Omission of this field MUST be interpreted as 662 "all optional fields are supported". An empty list MUST be 663 interpreted as "no optional fields are supported. Otherwise, 664 if a list of fields is provided, the fields in that list MUST 665 be interpreted as "the only optional fields that are 666 supported". 668 5.6.1. CDNI Logging Capability Object Serialization 670 The following shows an example of CDNI Logging Capability Object 671 Serialization, for a CDN that supports the optional Content 672 Collection ID logging field (but not the optional Session ID logging 673 field) for the "cdni_http_request_v1" record type. 675 { 676 "capabilities": [ 677 { 678 "capability-type": "FCI.Logging", 679 "capability-value": { 680 "record-type": "cdni_http_request_v1", 681 "fields": [ "s-ccid" ] 682 }, 683 "footprints": [ 684 685 ] 686 } 687 ] 688 } 690 The next example shows the CDNI Logging Capability Object 691 Serialization, for a CDN that supports all optional fields for the 692 "cdni_http_request_v1" record type. 694 { 695 "capabilities": [ 696 { 697 "capability-type": "FCI.Logging", 698 "capability-value": { 699 "record-type": "cdni_http_request_v1" 700 }, 701 "footprints": [ 702 703 ] 704 } 705 ] 706 } 708 5.7. CDNI Metadata Capability Object 710 The CDNI Metadata capability object is used to indicate support for 711 CDNI GenericMetadata types [I-D.ietf-cdni-metadata]. 713 Property: metadata 715 Description: List of supported CDNI GenericMetadata types. 717 Type: List of Strings corresponding to entries from the CDNI 718 Payload Type registry [RFC7736]) that correspond to CDNI 719 GenericMetadata objects. 721 Mandatory-to-Specify: Yes. An empty list MUST be interpreted 722 as "no GenericMetadata types are supported", i.e., "only 723 structural metadata and simple types are supported"; otherwise, 724 the list must be interpreted as containing "the only 725 GenericMetadata types that are supported" (in addition to 726 structural metadata and simple types) [I-D.ietf-cdni-metadata]. 728 5.7.1. CDNI Metadata Capability Object Serialization 730 The following shows an example of CDNI Metadata Capability Object 731 Serialization, for a CDN that supports only the SourceMetadata 732 GenericMetadata type (i.e., it can acquire and deliver content, but 733 cannot enforce and security policies, e.g., time, location, or 734 protocol ACLs). 736 { 737 "capabilities": [ 738 { 739 "capability-type": "FCI.Metadata", 740 "capability-value": { 741 "metadata": ["MI.SourceMetadata"] 742 }, 743 "footprints": [ 744 745 ] 746 } 747 ] 748 } 750 The next example shows the CDNI Metadata Capability Object 751 Serialization, for a CDN that supports only structural metadata 752 (i.e., it can parse metadata as a transit CDN, but cannot enforce 753 security policies or deliver content). 755 { 756 "capabilities": [ 757 { 758 "capability-type": "FCI.Metadata", 759 "capability-value": { 760 "metadata": [] 761 }, 762 "footprints": [ 763 764 ] 765 } 766 ] 767 } 769 6. IANA Considerations 771 6.1. CDNI Payload Types 773 This document requests the registration of the following CDNI Payload 774 Types under the IANA CDNI Payload Type registry: 776 +-------------------------+---------------+ 777 | Payload Type | Specification | 778 +-------------------------+---------------+ 779 | FCI.DeliveryProtocol | RFCthis | 780 | | | 781 | FCI.AcquisitionProtocol | RFCthis | 782 | | | 783 | FCI.RedirectionMode | RFCthis | 784 | | | 785 | FCI.Logging | RFCthis | 786 | | | 787 | FCI.Metadata | RFCthis | 788 +-------------------------+---------------+ 790 [RFC Editor: Please replace RFCthis with the published RFC number for 791 this document.] 793 6.1.1. CDNI FCI DeliveryProtocol Payload Type 795 Purpose: The purpose of this payload type is to distinguish FCI 796 advertisement objects for supported delivery protocols 798 Interface: FCI 800 Encoding: see Section 5.3 802 6.1.2. CDNI FCI AcquisitionProtocol Payload Type 804 Purpose: The purpose of this payload type is to distinguish FCI 805 advertisement objects for supported acquisition protocols 807 Interface: FCI 809 Encoding: see Section 5.4 811 6.1.3. CDNI FCI RedirectionMode Payload Type 813 Purpose: The purpose of this payload type is to distinguish FCI 814 advertisement objects for supported redirection modes 816 Interface: FCI 818 Encoding: see Section 5.5 820 6.1.4. CDNI FCI Logging Payload Type 822 Purpose: The purpose of this payload type is to distinguish FCI 823 advertisement objects for supported CDNI Logging record-types and 824 optional CDNI Logging Field Names. 826 Interface: FCI 828 Encoding: see Section 5.6 830 6.1.5. CDNI FCI Metadata Payload Type 832 Purpose: The purpose of this payload type is to distinguish FCI 833 advertisement objects for supported CDNI GenericMetadata types. 835 Interface: FCI 837 Encoding: see Section 5.7 839 6.2. Redirection Mode Registry 841 The IANA is requested to create a new "CDNI Capabilities Redirection 842 Modes" registry in the "Content Delivery Networks Interconnection 843 (CDNI) Parameters" category. The "CDNI Capabilities Redirection 844 Modes" namespace defines the valid redirection modes that can be 845 advertised as supported by a CDN. Additions to the Redirection Mode 846 namespace conform to the "IETF Review" policy as defined in 847 [RFC5226]. 849 The following table defines the initial Redirection Modes: 851 +------------------+----------------------------------+---------+ 852 | Redirection Mode | Description | RFC | 853 +------------------+----------------------------------+---------+ 854 | DNS-I | Iterative DNS-based Redirection | RFCthis | 855 | | | | 856 | DNS-R | Recursive DNS-based Redirection | RFCthis | 857 | | | | 858 | HTTP-I | Iterative HTTP-based Redirection | RFCthis | 859 | | | | 860 | HTTP-R | Recursive HTTP-based Redirection | RFCthis | 861 +------------------+----------------------------------+---------+ 863 [RFC Editor: Please replace RFCthis with the published RFC number for 864 this document.] 866 7. Security Considerations 868 This specification describes the semantics for capabilities and 869 footprint advertisement objects across interconnected CDNs. It does 870 not, however, specify a concrete protocol for transporting those 871 objects. Specific security mechanisms can only be selected for 872 concrete protocols that instantiate these semantics. This document 873 does, however, place some high-level security constraints on such 874 protocols. 876 All protocols that implement these semantics are REQUIRED to provide 877 integrity and authentication services. Without authentication and 878 integrity, an attacker could trivially deny service by forging a 879 footprint advertisement from a dCDN which claims the network has no 880 footprint or capability. This would prevent the uCDN from delegating 881 any requests to the dCDN. Since a pre-existing relationship between 882 all dCDNs and uCDNs is assumed by CDNI, the exchange of any necessary 883 credentials could be conducted before the FCI interface is brought 884 online. The authorization decision to accept advertisements would 885 also follow this pre-existing relationship and any contractual 886 obligations that it stipulates. 888 All protocols that implement these semantics are REQUIRED to provide 889 confidentiality services. Some dCDNs are willing to share 890 information about their footprint or capabilities with a uCDN but not 891 with other, competing dCDNs. For example, if a dCDN incurs an outage 892 that reduces footprint coverage temporarily, that could be 893 information the dCDN would want to share confidentially with the 894 uCDN. 896 As specified in this document, the security requirements of the FCI 897 could be met by transport-layer security mechanisms coupled with 898 domain certificates as credentials (e.g., TLS transport for HTTP as 899 per [RFC2818] and [RFC7230], with usage guidance from [RFC7525]) 900 between CDNs. There is no apparent need for further object-level 901 security in this framework, as the trust relationships it defines are 902 bilateral relationships between uCDNs and dCDNs rather than 903 transitive relationships. 905 8. References 907 8.1. Normative References 909 [I-D.ietf-cdni-logging] 910 Faucheur, F., Bertrand, G., Oprescu, I., and R. 911 Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- 912 logging-25 (work in progress), April 2016. 914 [I-D.ietf-cdni-metadata] 915 Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 916 "CDN Interconnection Metadata", draft-ietf-cdni- 917 metadata-16 (work in progress), April 2016. 919 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 920 Requirement Levels", BCP 14, RFC 2119, 921 DOI 10.17487/RFC2119, March 1997, 922 . 924 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 925 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 926 DOI 10.17487/RFC5226, May 2008, 927 . 929 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 930 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 931 2014, . 933 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 934 "Framework for Content Distribution Network 935 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 936 August 2014, . 938 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 939 DOI 10.17487/RFC7493, March 2015, 940 . 942 8.2. Informative References 944 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 945 DOI 10.17487/RFC2818, May 2000, 946 . 948 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 949 Distribution Network Interconnection (CDNI) Problem 950 Statement", RFC 6707, DOI 10.17487/RFC6707, September 951 2012, . 953 [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, 954 P., Ma, K., and G. Watson, "Use Cases for Content Delivery 955 Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, 956 November 2012, . 958 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 959 Protocol (HTTP/1.1): Message Syntax and Routing", 960 RFC 7230, DOI 10.17487/RFC7230, June 2014, 961 . 963 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 964 Network Interconnection (CDNI) Requirements", RFC 7337, 965 DOI 10.17487/RFC7337, August 2014, 966 . 968 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 969 "Recommendations for Secure Use of Transport Layer 970 Security (TLS) and Datagram Transport Layer Security 971 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 972 2015, . 974 [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) 975 Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, 976 December 2015, . 978 Appendix A. Main Use Case to Consider 980 Focusing on a main use case that contains a simple (yet somewhat 981 challenging), realistic, and generally imaginable scenario can help 982 in narrowing down the requirements for the CDNI FCI. To this end, 983 the following (simplified) use case can help in clarifying the 984 semantics of footprint and capabilities for CDNI. In particular, the 985 intention of the use case is to clarify what information needs to be 986 exchanged on the CDNI FCI, what types of information need to be 987 supported in a mandatory fashion (and which can be considered 988 optional), and what types of information need to be updated with 989 respect to a priori established CDNI contracts. 991 Use case: A given uCDN has several dCDNs. It selects one dCDN for 992 delivery protocol A and footprint 1 and another dCDN for delivery 993 protocol B and footprint 1. The dCDN that serves delivery protocol B 994 has a further, transitive (level-2) dCDN, that serves delivery 995 protocol B in a subset of footprint 1 where the first-level dCDN 996 cannot serve delivery protocol B itself. What happens if 997 capabilities change in the transitive level-2 dCDN that might affect 998 how the uCDN selects a level-1 dCDN (e.g., in case the level-2 dCDN 999 cannot serve delivery protocol B anymore)? How will these changes be 1000 conveyed to the uCDN? In particular, what information does the uCDN 1001 need to be able to select a new first-level dCDN, either for all of 1002 footprint 1 or only for the subset of footprint 1 that the transitive 1003 level-2 dCDN served on behalf of the first-level dCDN? 1005 Appendix B. Semantics for Footprint Advertisement 1007 Roughly speaking, "footprint" can be defined as "ability and 1008 willingness to serve" by a dCDN. However, in addition to simple 1009 "ability and willingness to serve", the uCDN could want additional 1010 information to make a dCDN selection decision, e.g., "how well" a 1011 given dCDN can actually serve a given end user request. The "ability 1012 and willingness" to serve SHOULD be distinguished from the subjective 1013 qualitative measurement of "how well" it was served. One can imagine 1014 that such additional information is implicitly associated with a 1015 given footprint, due to contractual agreements, SLAs, business 1016 relationships, or past perceptions of dCDN quality. As an 1017 alternative, such additional information could also be explicitly 1018 tagged along with the footprint. 1020 It is reasonable to assume that a significant part of the actual 1021 footprint advertisement will happen in contractual agreements between 1022 participating CDNs, prior to the advertisement phase using the CDNI 1023 FCI. The reason for this assumption is that any contractual 1024 agreement is likely to contain specifics about the dCDN coverage 1025 (footprint) to which the contractual agreement applies. In 1026 particular, additional information to judge the delivery quality 1027 associated with a given dCDN footprint might be defined in 1028 contractual agreements, outside of the CDNI FCI. Further, one can 1029 assume that dCDN contractual agreements about the delivery quality 1030 associated with a given footprint will probably be based on high- 1031 level aggregated statistics and not too detailed. 1033 Given that a large part of footprint advertisement will actually 1034 happen in contractual agreements, the semantics of CDNI footprint 1035 advertisement refer to answering the following question: what exactly 1036 still needs to be advertised by the CDNI FCI? For instance, updates 1037 about temporal failures of part of a footprint can be useful 1038 information to convey via the CDNI request routing interface. Such 1039 information would provide updates on information previously agreed in 1040 contracts between the participating CDNs. In other words, the CDNI 1041 FCI is a means for a dCDN to provide changes/updates regarding a 1042 footprint it has prior agreed to serve in a contract with a uCDN. 1044 Generally speaking, one can imagine two categories of footprint to be 1045 advertised by a dCDN: 1047 o Footprint could be defined based on "coverage/reachability", where 1048 coverage/reachability refers to a set of prefixes, a geographic 1049 region, or similar boundary. The dCDN claims that it can cover/ 1050 reach 'end user requests coming from this footprint'. 1052 o Footprint could be defined based on "resources", where resources 1053 refers to surrogates a dCDN claims to have (e.g., the location of 1054 surrogates/resources). The dCDN claims that 'from this footprint' 1055 it can serve incoming end user requests. 1057 For each of these footprint types, there are capabilities associated 1058 with a given footprint: 1060 o capabilities such as delivery protocol, redirection mode, and 1061 metadata, which are supported in the coverage area for a 1062 "coverage/reachability" defined footprint, or 1064 o capabilities of resources, such as delivery protocol, redirection 1065 mode, and metadata, which apply to a "resource" defined footprint. 1067 "Resource" types of footprints are more specific than "coverage/ 1068 reachability" types of footprints, where the actual coverage/ 1069 reachability are extrapolated from the resource location (e.g., 1070 netmask applied to resource IP address to derive IP-prefix). The 1071 specific methods for extrapolating coverage/reachability from 1072 resource location are beyond the scope of this document. In the 1073 degenerate case, the resource address could be specified as a 1074 coverage/reachability type of footprint, in which case no 1075 extrapolation is necessary. Resource types of footprints could 1076 expose the internal structure of a CDN network which could be 1077 undesirable. As such, the resource types of footprints are not 1078 considered mandatory to support for CDNI. 1080 Footprints can be viewed as constraints for delegating requests to a 1081 dCDN: A dCDN footprint advertisement tells the uCDN the limitations 1082 for delegating a request to the dCDN. For IP prefixes or ASN(s), the 1083 footprint signals to the uCDN that it should consider the dCDN a 1084 candidate only if the IP address of the request routing source falls 1085 within the prefix set (or ASN, respectively). The CDNI 1086 specifications do not define how a given uCDN determines what address 1087 ranges are in a particular ASN. Similarly, for country codes a uCDN 1088 should only consider the dCDN a candidate if it covers the country of 1089 the request routing source. The CDNI specifications do not define 1090 how a given uCDN determines the country of the request routing 1091 source. Multiple footprint constraints are additive: the 1092 advertisement of different types of footprint narrows the dCDN 1093 candidacy cumulatively. 1095 Independent of the exact type of a footprint, a footprint might also 1096 include the connectivity of a given dCDN to other CDNs that are able 1097 to serve content to users on behalf of that dCDN, to cover cases with 1098 cascaded CDNs. Further, the dCDN needs to be able to express its 1099 footprint to an interested uCDN in a comprehensive form, e.g., as a 1100 data set containing the complete footprint. Making incremental 1101 updates, however, to express dynamic changes in state is also 1102 desirable. 1104 Appendix C. Semantics for Capabilities Advertisement 1106 In general, the dCDN needs to be able to express its general 1107 capabilities to the uCDN. These general capabilities could express 1108 if the dCDN supports a given service, for instance, HTTP vs HTTPS 1109 delivery. Furthermore, the dCDN needs to be able to express 1110 particular capabilities for the delivery in a particular footprint 1111 area. For example, the dCDN might in general offer HTTPS but not in 1112 some specific areas, either for maintenance reasons or because the 1113 surrogates covering this particular area cannot deliver this type of 1114 service. Hence, in certain cases footprint and capabilities are tied 1115 together and cannot be interpreted independently from each other. In 1116 such cases, i.e., where capabilities need to be expressed on a per 1117 footprint basis, it could be beneficial to combine footprint and 1118 capabilities advertisement. 1120 A high-level and very rough semantic for capabilities is thus the 1121 following: Capabilities are types of information that allow a uCDN to 1122 determine if a dCDN is able (and willing) to accept (and properly 1123 handle) a delegated content request. In addition, Capabilities are 1124 characterized by the fact that this information can change over time 1125 based on the state of the network or surrogates. 1127 At a first glance, several broad categories of capabilities seem 1128 useful to convey via an advertisement interface, however, advertising 1129 capabilities that change highly dynamically (e.g., real-time delivery 1130 performance metrics, CDN resource load, or other highly dynamically 1131 changing QoS information) is beyond the scope for CDNI FCI. First, 1132 out of the multitude of possible metrics and capabilities, it is hard 1133 to agree on a subset and the precise metrics to be used. Second, it 1134 seems infeasible to specify such highly dynamically changing 1135 capabilities and the corresponding metrics within a reasonable time- 1136 frame. 1138 Useful capabilities refer to information that does not change highly 1139 dynamically and which in many cases is absolutely necessary to decide 1140 on a particular dCDN for a given end user request. For instance, if 1141 an end user request concerns the delivery of a video file with a 1142 certain protocol, the uCDN needs to know if a given dCDN has the 1143 capability of supporting this delivery protocol. 1145 Similar to footprint advertisement, it is reasonable to assume that a 1146 significant part of the actual (resource) capabilities advertisement 1147 will happen in contractual agreements between participating CDNs, 1148 i.e., prior to the advertisement phase using the CDNI FCI. The role 1149 of capability advertisement is hence rather to enable the dCDN to 1150 update a uCDN on changes since a contract has been set up (e.g., in 1151 case a new delivery protocol is suddenly being added to the list of 1152 supported delivery protocols of a given dCDN, or in case a certain 1153 delivery protocol is suddenly not being supported anymore due to 1154 failures). Capabilities advertisement thus refers to conveying 1155 information to a uCDN about changes/updates of certain capabilities 1156 with respect to a given contract. 1158 Given these semantics, it needs to be decided what exact capabilities 1159 are useful and how these can be expressed. Since the details of CDNI 1160 contracts are not known at the time of this writing (and the CDNI 1161 interface are better off being agnostic to these contracts anyway), 1162 it remains to be seen what capabilities will be used to define 1163 agreements between CDNs in practice. One implication for 1164 standardization could be to initially only specify a very limited set 1165 of mandatory capabilities for advertisement and have on top of that a 1166 flexible data model that allows exchanging additional capabilities 1167 when needed. Still, agreement needs to be found on which 1168 capabilities (if any) will be mandatory among CDNs. 1170 It is not feasible to enumerate all the possible options for the 1171 mandatory capabilities listed above (e.g., all the potential delivery 1172 protocols or metadata options) or anticipate all the future needs for 1173 additional capabilities. It would be unreasonable to burden the CDNI 1174 FCI specification with defining each supported capability. Instead, 1175 the CDNI FCI specification should define a generic protocol for 1176 conveying any capability information (e.g. with common encoding, 1177 error handling, and security mechanism; further requirements for the 1178 CDNI FCI Advertisement Interface are listed in [RFC7337]). 1180 Appendix D. Acknowledgment 1182 Jan Seedorf is partially supported by the GreenICN project (GreenICN: 1183 Architecture and Applications of Green Information Centric 1184 Networking), a research project supported jointly by the European 1185 Commission under its 7th Framework Program (contract no. 608518) and 1186 the National Institute of Information and Communications Technology 1187 (NICT) in Japan (contract no. 167). The views and conclusions 1188 contained herein are those of the authors and should not be 1189 interpreted as necessarily representing the official policies or 1190 endorsements, either expressed or implied, of the GreenICN project, 1191 the European Commission, or NICT. 1193 Martin Stiemerling provided initial input to this document and 1194 valuable comments to the ongoing discussions among the authors of 1195 this document. Thanks to Francois Le Faucheur and Scott Wainner for 1196 providing valuable comments and suggestions to the text. 1198 Authors' Addresses 1200 Jan Seedorf 1201 NEC 1202 Kurfuerstenanlage 36 1203 Heidelberg 69115 1204 Germany 1206 Phone: +49 6221 4342 221 1207 Fax: +49 6221 4342 155 1208 Email: seedorf@neclab.eu 1210 Jon Peterson 1211 NeuStar 1212 1800 Sutter St Suite 570 1213 Concord CA 94520 1214 USA 1216 Email: jon.peterson@neustar.biz 1218 Stefano Previdi 1219 Cisco Systems 1220 Via Del Serafico 200 1221 Rome 0144 1222 Italy 1224 Email: sprevidi@cisco.com 1225 Ray van Brandenburg 1226 TNO 1227 Brassersplein 2 1228 Delft 2612CT 1229 The Netherlands 1231 Phone: +31-88-866-7000 1232 Email: ray.vanbrandenburg@tno.nl 1234 Kevin J. Ma 1235 Ericsson 1236 43 Nagog Park 1237 Acton, MA 01720 1238 USA 1240 Phone: +1 978-844-5100 1241 Email: kevin.j.ma@ericsson.com