idnits 2.17.1 draft-ma-cdni-metadata-01.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2011) is 4559 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 (-01) exists of draft-davie-cdni-framework-00 == Outdated reference: A later version (-17) exists of draft-ietf-cdni-requirements-01 == Outdated reference: A later version (-10) exists of draft-ietf-cdni-use-cases-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Ma 3 Internet-Draft Azuki Systems, Inc. 4 Intended status: Standards Track October 31, 2011 5 Expires: May 3, 2012 7 Content Distribution Network Interconnection (CDNI) Metadata Interface 8 draft-ma-cdni-metadata-01 10 Abstract 12 Content publishers (CPs) often use multiple Content Delivery Networks 13 (CDNs) to deliver content to consumers. Though existing interactions 14 between CPs and individual CDNs are beyond the scope of CDN 15 interconnection (CDNI), it is important to understand the management 16 capabilities and features available with existing non-interconnected 17 multi-CDN deployments. Before migrating to CDNI, CPs must first 18 assess the suitability of CDNI as a replacement for their existing 19 non-interconnected multi-CDN deployments. CDN feature configuration 20 and capability advertisement and enforcement is likely to occur 21 through the CDNI metadata interface (MI). This document describes an 22 approach to implementing the CDNI MI through the use of an extensible 23 metadata model and a light-weight HTTP-based API. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 3, 2012. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 66 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 67 2. CDNI Metadata Data Model . . . . . . . . . . . . . . . . . . . 6 68 2.1. Domain Table . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.2. Base Address Table . . . . . . . . . . . . . . . . . . . . 7 70 2.2.1. Hierarchical Base Addresses . . . . . . . . . . . . . 8 71 2.3. Agent Table . . . . . . . . . . . . . . . . . . . . . . . 9 72 2.4. Metadata Table . . . . . . . . . . . . . . . . . . . . . . 10 73 2.4.1. Hierarchical Metadata . . . . . . . . . . . . . . . . 12 74 3. CDNI Metadata Protocol . . . . . . . . . . . . . . . . . . . . 13 75 3.1. Domain API . . . . . . . . . . . . . . . . . . . . . . . . 14 76 3.1.1. Domain Creation . . . . . . . . . . . . . . . . . . . 14 77 3.1.2. Domain Update . . . . . . . . . . . . . . . . . . . . 14 78 3.1.3. Domain Retrieval . . . . . . . . . . . . . . . . . . . 15 79 3.1.4. Domain Removal . . . . . . . . . . . . . . . . . . . . 15 80 3.1.5. Domain Errors . . . . . . . . . . . . . . . . . . . . 16 81 3.2. Agent API . . . . . . . . . . . . . . . . . . . . . . . . 16 82 3.2.1. Agent Creation . . . . . . . . . . . . . . . . . . . . 16 83 3.2.2. Agent Update . . . . . . . . . . . . . . . . . . . . . 17 84 3.2.3. Agent Retrieval . . . . . . . . . . . . . . . . . . . 17 85 3.2.4. Agent Removal . . . . . . . . . . . . . . . . . . . . 18 86 3.2.5. Agent Errors . . . . . . . . . . . . . . . . . . . . . 18 87 3.3. Metadata API . . . . . . . . . . . . . . . . . . . . . . . 18 88 3.3.1. Metadata Creation . . . . . . . . . . . . . . . . . . 19 89 3.3.2. Metadata Update . . . . . . . . . . . . . . . . . . . 21 90 3.3.3. Metadata Retrieval . . . . . . . . . . . . . . . . . . 22 91 3.3.4. Metadata Removal . . . . . . . . . . . . . . . . . . . 26 92 3.3.5. Metadata Errors . . . . . . . . . . . . . . . . . . . 27 93 3.3.6. Metadata Prepositioning . . . . . . . . . . . . . . . 27 94 4. Metadata Definitions . . . . . . . . . . . . . . . . . . . . . 27 95 4.1. Origin Server . . . . . . . . . . . . . . . . . . . . . . 27 96 4.2. Activation Time . . . . . . . . . . . . . . . . . . . . . 28 97 4.3. Deactivation Time . . . . . . . . . . . . . . . . . . . . 28 98 4.4. Administrative Disable . . . . . . . . . . . . . . . . . . 29 99 4.5. Delegation Disable . . . . . . . . . . . . . . . . . . . . 29 100 4.6. Footprint Filter . . . . . . . . . . . . . . . . . . . . . 29 101 4.7. HTTP Header Filter . . . . . . . . . . . . . . . . . . . . 30 102 4.8. Protocol Filter . . . . . . . . . . . . . . . . . . . . . 30 103 4.9. SSL Required . . . . . . . . . . . . . . . . . . . . . . . 31 104 4.10. SSL Client Authentication Required . . . . . . . . . . . . 31 105 4.11. URL Hash . . . . . . . . . . . . . . . . . . . . . . . . . 32 106 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 107 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 108 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 109 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 110 8.1. Normative References . . . . . . . . . . . . . . . . . . . 33 111 8.2. Informative References . . . . . . . . . . . . . . . . . . 33 112 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33 114 1. Introduction 116 The use cases described in the CDNI use case document 117 [I-D.ietf-cdni-use-cases] provide motivational use cases for CDN 118 interconnection (CDNI). They describe reasons and situations where 119 CDNI provides a benefit to CDN vendors as well as content service 120 providers (CSPs). Additional use cases exist which describe how CDNs 121 are used today, however, these use cases often involve specific 122 features (e.g., customized content transformations, content security, 123 client authentication and filtering, content acquisition optimization 124 and redundancy, etc.) which are beyond the scope of CDNI. Though the 125 features themselves are not relevant to CDNI, the ability to support 126 those features or enforce policies related to those features in a 127 generic and extensible manner should be considered when designing 128 CDNI interfaces. The ability to support feature parity with existing 129 deployment models (i.e., non-CDNI-based CDN federation) may help to 130 remove barriers to CDNI adoption. 132 Though certain interfaces are out of scope of CDNI, e.g.: 134 o upstream CDN (uCDN) configuration by the CP 136 o uCDN content acquisition 138 o uCDN content delivery 140 o downstream CDN (dCDN) content acquisition 142 o end user (EU) content acquisition 144 o third party workflow management 146 o third party request routing 148 An awareness of these interfaces and an understanding of the 149 restrictions which they may impose on CDNI request routing is useful 150 for understanding the needs of the CDNI metadata interface (MI). As 151 described in the "Dynamic CDNI Metadata Acquisition Example" section 152 in the CDNI framework document [I-D.davie-cdni-framework], upon 153 receiving a request routing interface (RRI) request, the MI MAY be 154 used to retrieve metadata that is "considered" before responding to 155 the RRI request. To that end, the MI MUST define a deterministic 156 method for handling metadata processing. Though the definition and 157 interpretation of any individual piece of metadata is beyond the 158 scope of CDNI, a well-defined method for how to respond to a RRI 159 request when any unknown metadata value is encountered MUST be 160 supported. 162 This document describes a simple data model for representing CDNI 163 metadata and a simple protocol for creating and retrieving CDNI 164 metadata in an opaque manner. The term opaque, in this case, should 165 be understood to mean: without understanding the underlying meaning 166 or interpretation of the metadata being represented. The metadata 167 model and retrieval protocol SHOULD be completely independent of the 168 definition of individual metadata values. The metadata model and 169 retrieval protocol MUST also define default behaviors for dealing 170 with metadata processing errors. The document defines a list of 171 metadata which are likely applicable to a broad range of CDNI 172 deployments. The document also provides a separate list of metadata 173 which are likely to be desirable to content publishers (CPs). This 174 document is not intended to suggest that any additional interfaces or 175 requirements are needed beyond those already specified in the CDNI 176 requirements document [I-D.ietf-cdni-requirements], nor is this 177 document intended to suggest that any out of scope interfaces or 178 content publisher feature functionality should be brought into scope. 179 The metadata examples provided are intended only to illustrate 180 possible features that interconnected CDNs may wish to support and 181 the extensibility of the metadata model to handle those situations. 183 1.1. Terminology 185 [Ed. insert terminology reference] 187 1.2. Abbreviations 189 o CDN: Content Distribution Network 191 o uCDN: Upstream Content Distribution Network 193 o dCDN: Downstream Content Distribution Network 195 o CDNI: Content Distribution Network Interconnection 197 o CP: Content Publisher 199 o CSP: Content Service Provider 201 o EU: End User 203 o NSP: Network Service Provider 205 o RRI: Request Routing Interface 207 o MI: Metadata Interface 208 o CI: Control Interface 210 2. CDNI Metadata Data Model 212 The simple data model is shown in Figure 1 below. It includes a top 213 level Domain object which describes the site(s) to which metadata is 214 associated. The term site, in this case, should be understood to 215 mean a collection of related content assets access through a single 216 portal or Web-site. The Domain is associated with zero or more 217 opaque Metadata objects. Each Metadata object is associated with one 218 or more Base Address objects. The Metadata objects are each 219 associated with a URI within the Domain and accessible through any of 220 the Base Addresses. A combination of Base Address and URI prefix 221 matching is used identify Metadata to allow for hierarchical 222 associations between individual Metadata and sets of content items. 223 Each Domain is also associated with one or more Agent objects. 224 Agents represent entities which require access to metadata (e.g., 225 CPs, uCDNs, or dCDNs). An Agent is associated with each Metadata 226 entry allowing different Metadata values to be returned to different 227 Agents. 229 +----------+ 230 | | 1 231 | Agent +---------------+ 232 | | | 233 +----+-----+ | 234 | 1..* | 235 | | 236 | 1 | 0..* 237 +----+-----+ +----+-----+ +----------+ 238 | | 1 0..* | | 1 1..* | | 239 | Domain +----------+ Metadata +----------+ BaseAddr | 240 | | | | | | 241 +----+-----+ +----------+ +----------+ 243 Figure 1: CDNI Metadata Data Model 245 Note: The data model described above is not a strict data model for 246 specific metadata, it is a data model which contains components 247 necessary for implementing the CDNI MI. Not all information need be 248 distributed through the MI. Some information (e.g., Domains and 249 Agents) may be necessary for the MI to function, but MAY be 250 negotiated or implemented out-of-band. They could be configured 251 either by the CDN as part of a non-CDNI process, or through the CDNI 252 control interface (CI) bootstrapping process, or using the MI APIs 253 described herein. The MI APIs may also be used by CDNs, internally, 254 to configure themselves. The complete data model and full set of 255 APIs are provided as part of a holistic MI description. 257 The following sections describe an example implementation of the 258 metadata scheme described above using a standard SQL database. 260 2.1. Domain Table 262 The Domain object contains basic information related to the site 263 being described. The example shown contains a primary key index and 264 a unique name for the site. An OPTIONAL site description (e.g., a 265 textual description of the site and its content) and site provider 266 (e.g., the name of the CP or CSP which owns the content) information 267 is also included. 269 CREATE TABLE "domain" ("domain_id" serial primary key, 270 "name" character varying(255) NOT NULL, 271 "provider" character varying(255), 272 "description" character varying(4095)); 273 CREATE UNIQUE INDEX index_domain ON domain (name); 275 The Domain is the central object for binding Metadata. The example 276 Domain shown below highlights the descriptive nature of the Domain 277 object: 279 domain_id: 1 280 name: acme 281 provider: acme rocket-powered products, inc 282 description: fine purveyors of high quality anvils, rubber bands, 283 bird seed, and rocket powered footwear 285 2.2. Base Address Table 287 The Base Address object contains basic hostname and base URI 288 information related to the site being accessed. The example shown 289 requires a primary key index, a string containing the hostname and 290 base URI, and a foreign key reference to the Metadata to which this 291 Base Address is associated. A uniqueness constraint is imposed on 292 baseaddr/metadata_id pairs to prevent duplicate Base Address entries 293 for a given Metadata. 295 CREATE TABLE "baseaddr" ("baseaddr_id" serial primary key, 296 "baseaddr" character varying(255) NOT NULL, 297 "metadata_id" integer NOT NULL); 298 CREATE UNIQUE INDEX index_baseaddr ON baseaddr (baseaddr, metadata_id); 300 Base Address Table Definition 302 The Base Address objects allows multiple hostname and base URI pairs 303 to be associated with each Metadata object denoting the list of Base 304 Addresses through which content within the Domain may be accessed. 305 There are many cases where different Base Addresses are used to 306 access the same content, e.g.: 308 o internal vs. external addresses: content may be accessible via 309 both internal 10-net IP addresses and their associated DNS 310 addresses and base URIs, as well as publicly routable external IP 311 addresses and their associated DNS addresses and base URIs, where 312 all of the addresses point to the same content servers and the 313 base URIs are mapped to the same base directories, 315 o service white-labeling: multiple CSPs may provide access to the 316 same content through different branded services where each branded 317 service has its own DNS address and/or base URI, but all of the 318 services point to the same content, or 320 o analytics partitioning: redirects from other sites may use 321 different DNS addresses and/or base URIs, so that they may be 322 easily accounted for, while still pointing at the same content. 324 The example Base Addresses shown below represent two DNS addresses 325 through which content may be accessed as well as an internal IP 326 address which may be used for staging: 328 baseaddr_id: 1 329 baseaddr: wile.e.coyote.acme.com 330 metadata_id: 1 332 baseaddr_id: 2 333 baseaddr: road.runner.acme.com 334 metadata_id: 1 336 baseaddr_id: 3 337 baseaddr: 10.10.10.10/meemeep 338 metadata_id: 1 340 Note: The exact schema described above may result in heavy 341 duplication of Base Addresses. It is presented as an example for its 342 simplicity, however, it may be optimized by using other table joining 343 scheme implementations. 345 2.2.1. Hierarchical Base Addresses 347 In order to support hierarchical Base Addresses, the wildcard '*.' 348 SHOULD be allowed as the first part of DNS-type Base Addresses. The 349 wildcard does not make sense at the beginning of IP Address-type Base 350 Addresses. While a wildcard at the end of IP Address-type Base 351 Addresses would make more sense, support for IP Address-type Base 352 Addresses is OPTIONAL. The wildcard signifies the applicability of 353 the associated Metadata value to all Base Addresses which match the 354 address suffix. 356 The following two Base Addresses condense the previous example by 357 allowing all acme.com DNS addresses: 359 baseaddr_id: 1 360 baseaddr: *.acme.com 361 metadata_id: 1 363 baseaddr_id: 2 364 baseaddr: 10.10.10.10/meemeep 365 metadata_id: 1 367 Note: There is no explicit enforcement that Base Addresses associated 368 with a given piece of Metadata not overlap, however, for performance 369 reasons, Base Addresses associated with a given piece of Metadata 370 SHOULD NOT be allowed to overlap. 372 2.3. Agent Table 374 The Agent object contains basic information for authenticating 375 entities which require access to Metadata. The example shown 376 contains a primary key index, a string containing the username, an 377 OPTIONAL string containing the password (possibly hashed or 378 encrypted), a boolean value for differentiating between full read/ 379 write access (e.g., for uCDNs) and read only access (e.g., for 380 dCDNs), and a foreign key reference to the Domain to which this Agent 381 is associated. A uniqueness constraint is imposed on username/ 382 domain_id pairs to prevent duplicate Agent entries for a given 383 Domain. 385 CREATE TABLE "agent" ("agent_id" serial primary key, 386 "username" character varying(255) NOT NULL, 387 "password" character varying(255), 388 "read_only" boolean DEFAULT false NOT NULL, 389 "domain_id" integer NOT NULL); 390 CREATE UNIQUE INDEX index_agent ON agent (username, domain_id); 392 Agent Table Definition 394 Note: The password field is included to support the HTTP 395 authentication described in the API sections, however, if alternate 396 authentication schemes are used, the password may not be necessary. 398 The Agent objects manage Metadata access rights. The Agent 399 functionality as described attempts to address two issues: 401 o security concerns: where unauthorized injection or deletion of 402 Metadata may alter the functionality of a content service and MUST 403 be prevented, as described in the Security Considerations section, 404 and 406 o customization requirements: where retrieval of certain metadata 407 may require different responses depending on the Agent who is 408 accessing the Metadata. 410 Note: Though both of the above issues could be addressed though means 411 outside of the MI, or through a means common to all of the CDNI 412 interfaces, the Agent serves the purpose of addressing these needs 413 within the context of the MI, in lieu of a consensus alternative. 415 The example Agents shown below represent a uCDN Agent with write 416 privileges and a dCDN Agent with read-only permissions: 418 agent_id: 1 419 username: ucdn 420 password: xxx 421 read_only: false 422 domain_id: 1 424 agent_id: 2 425 username: dcdn 426 password: yyy 427 read_only: true 428 domain_id: 1 430 2.4. Metadata Table 432 The Metadata object contains the actual individual pieces of metadata 433 for the site being described. The example shown contains a primary 434 key index, a string containing the URI(s) to which the metadata 435 applies, a name/value pair of strings which represent the name and 436 value of the Metadata, respectively, as well as a boolean value 437 stating whether or not enforcement of the given Metadata is 438 mandatory. An OPTIONAL ttl value and timeout field are included to 439 support metadata invalidation. The table also contains a foreign key 440 reference to the Domain to which this Metadata is associated and a 441 foreign key reference to the Agent to whom this Metadata is intended. 442 A compound uniqueness constraint is also applied to each uri/name/ 443 domain_id/agent_id tuple to prevent a given Metadata from being 444 ambiguously applied multiple times to the same URI in a given Domain 445 for a given Agent. 447 CREATE TABLE "metadata" ("metadata_id" serial primary key, 448 "uri" character varying(4095) NOT NULL, 449 "name" character varying(255) NOT NULL, 450 "value" character varying(4095) NOT NULL, 451 "mandatory" boolean DEFAULT false NOT NULL, 452 "ttl" integer DEFAULT 0 NOT NULL, 453 "timeout" timestamp without time zone, 454 "domain_id" integer NOT NULL, 455 "agent_id" integer NOT NULL); 456 CREATE UNIQUE INDEX index_metadata ON metadata (uri, name, 457 domain_id, agent_id); 459 The name/value pair is represented as simple opaque strings. The MI 460 has no understanding of any inherent meaning for the Metadata names 461 or values. Metadata names SHOULD be properly defined and registered, 462 and any implied functionality SHOULD be agreed upon a priori by CDN 463 operators, however, these negotiations are beyond the scope of CDNI. 465 The intent of the mandatory boolean is to identify Metadata that MUST 466 be enforced by all CDNs. If a CDN is unable to understand or is 467 unable to comply with the Metadata, it MUST NOT deliver the content 468 being requests. For dCDNs, the mandatory flag defines how to respond 469 to RRI requests when unknown Metadata is encountered. If Metadata is 470 marked as mandatory, then the dCDN MUST NOT accept the RRI request if 471 it does not know how to process that piece of Metadata (e.g., the 472 named Metadata is not supported, the Metadata value is invalid, or 473 the Metadata value is not supported). If the MI request resulted 474 from a "recursive" RRI request, then the dCDN MUST return an error to 475 the uCDN. If the MI request resulted from an "iterative" RRI 476 request, then the dCDN MUST respond with a 403 Forbidden status code 477 to the EU. 479 The OPTIONAL ttl value is provided to allow configuration of a 480 Metadata TTLs. The ttl MUST be specified in seconds and the timeout 481 field SHOULD be populated by the local MI processor and used 482 internally, to prevent the need for clock synchronization between MI 483 processors. 485 The association of each Metadata to an Agent allows different Agents 486 to retrieve different Metadata values for a given URI in the given 487 Domain. This is intended to allow CDNs to separate upstream Metadata 488 from downstream Metadata (e.g., a uCDN content acquisition URL may 489 point to a CP origin, however, the content acquisition URL that the 490 dCDN retrieves from the uCDN may point at a surrogate in the uCDN). 491 Though this information could be hidden within each CDN's 492 implementation, explicitly representing this in the data model 493 reduces ambiguity in Metadata retrieval. 495 2.4.1. Hierarchical Metadata 497 In order to support hierarchical metadata, '/*' SHOULD be allowed as 498 the last part of the URI hierarchy, signifying the application of 499 this Metadata value to all URIs which match this URI prefix. If 500 multiple Metadata are defined with overlapping prefixes, the URI with 501 the longest prefix match MUST be used. The uniqueness constraint on 502 the uri/name/domain_id tuple should allow for unambiguous resolution 503 of Metadata priority. 505 Given the following three Metadata, the value of the color Metadata 506 object is defined four times within the same Domain but for different 507 URIs and Agents: 509 metadata_id: 1 510 uri: /* 511 name: color 512 value: blue 513 mandatory: false 514 ttl: 0 515 domain_id: 1 516 agent_id: 2 518 metadata_id: 1 519 uri: /* 520 name: color 521 value: gold 522 mandatory: false 523 ttl: 0 524 domain_id: 1 525 agent_id: 1 527 metadata_id: 2 528 uri: /grass/* 529 name: color 530 value: brown 531 mandatory: false 532 ttl: 0 533 domain_id: 1 534 agent_id: 2 536 metadata_id: 3 537 uri: /grass/on/the/other/side/* 538 name: color 539 value: green 540 mandatory: false 541 ttl: 0 542 domain_id: 1 543 agent_id: 2 545 The default value for the color metadata (signified by the all 546 encompassing URI "/*") is blue for the dCDN Agent and gold for the CP 547 Agent. Alternate colors are associated with requests from the dCDN 548 Agent for URIs that begin with "/grass". By default /grass has a 549 color of brown, except when requesting "/grass/on/the/other/side/" 550 which is green. 552 3. CDNI Metadata Protocol 554 The Domain, Agent, and Metadata creation/retrieval protocols are 555 defined in the following sections. All use a simple HTTP-based 556 approach. The protocol, in general, SHOULD be data format agnostic. 557 The examples shown herein use an XML representation for MI requests/ 558 responses, however, other well-defined representations (e.g., JSON) 559 are also acceptable. The protocol shown provides an example of the 560 functionality required to support the data model described in Section 561 2, however, any protocol which allows for the creation, modification, 562 retrieval, and removal of Domains, Agents, and Metadata could also be 563 acceptable. 565 It is assumed that a well-known hostname to which MI requests should 566 be sent is configured through the CDNI bootstrap data. Bootstrap 567 information is sent through the CDNI CI, as described in the CDNI 568 requirements document [I-D.ietf-cdni-requirements]. This CDNI MI 569 bootstrap data corresponds to the MI SEED information described in 570 the CDNI framework document [I-D.davie-cdni-framework]. The MI APIs 571 described herein are intended to be serviced by the MI running on 572 that host. The actual entity which processes the requests is 573 inconsequential, as long as it has access to the metadata database. 575 Domain and Agent configurations must exist prior to Metadata 576 creation/retrieval. Domains and Agents MAY be created as a part of 577 an off-line business negotiation process or as a part of the CDNI 578 bootstrapping process. Domains and Agents do not necessarily need to 579 be created dynamically using the APIs described below, however, the 580 APIs are included for completeness. When the Domain and Agent APIs 581 are used, access to the APIs SHOULD be secured using SSL with client 582 authentication as described in the Security Considerations section. 584 New content and Metadata MAY be uploaded at any time. The Metadata 585 API MUST support dynamic creation and modification of Metadata by 586 valid Agents. Though the Metadata API SHOULD also be secured using 587 SSL with client authentication as described in the Security 588 Considerations section (using a different client certificate than 589 that used for the Domain and Agents APIs), an additional Agent 590 authentication mechanism is REQUIRED to properly filter requests and 591 results. In the examples shown below, HTTP basic authentication is 592 used for Agent authentication, though other methods (e.g., HTTP 593 digest authentication or URL hashing) could also be used. 595 3.1. Domain API 597 Domain creation/update is distinguished from domain retrieval by the 598 HTTP method. Domain creation/update MUST use the POST method. 599 Domain retrieval MUST use the GET method. Domain removal MUST use 600 the DELETE method. 602 All metadata MUST be associated with a Domain. A Domain is created/ 603 modified/retrieved using the "/CDNI/MI/domain" API. The domain API 604 REQUIRES a single query string argument "domain" which specifies the 605 name of the Domain to be created/modified/retrieved. 607 A simple XML representation of the information provided to the domain 608 creation/update API or returned from the domain retrieval API is 609 shown below: 611 612 613 614 616 3.1.1. Domain Creation 618 The following example creates a new Domain "acme": 620 POST /CDNI/MI/domain?domain=acme HTTP/1.1 621 Host: host.mi.cdni.example.com 622 Accept: */* 623 Content-Length: 81 624 Content-Type: application/x-www-form-urlencoded 626 627 acme 628 acme 629 631 3.1.2. Domain Update 633 The following example updates the "acme" Domain: 635 POST /CDNI/MI/domain?domain=acme HTTP/1.1 636 Host: host.mi.cdni.example.com 637 Accept: */* 638 Content-Length: 209 639 Content-Type: application/x-www-form-urlencoded 641 642 acme rocket-powered products, inc 643 fine purveyors of high quality anvils, rubber bands, 644 bird seed, and rocket powered footwear 645 647 3.1.3. Domain Retrieval 649 The following example retrieves the updated "acme" Domain 650 information: 652 GET /CDNI/MI/domain?domain=acme HTTP/1.1 653 Host: host.mi.cdni.example.com 654 Accept: */* 656 HTTP/1.1 200 OK 657 Content-Length: 209 658 Connection: close 659 Content-Type: text/xml 661 662 acme rocket-powered products, inc 663 fine purveyors of high quality anvils, rubber bands, 664 bird seed, and rocket powered footwear 665 667 The MI MAY support bulk retrieval of Domains through the use of a 668 comma separated list of Domain names in the domain query string 669 parameter. 671 3.1.4. Domain Removal 673 The following example removes the "acme" Domain: 675 DELETE /CDNI/MI/domain?domain=acme HTTP/1.1 676 Host: host.mi.cdni.example.com 677 Accept: */* 679 3.1.5. Domain Errors 681 Any update or retrieval request with malformed XML SHOULD respond 682 with a 400 Bad Request status code. Ancillary unknown tags MAY be 683 ignored. 685 Any update or retrieval request for a Domain which does not exist 686 SHOULD respond with a 404 Not Found status code. 688 3.2. Agent API 690 Agent creation/update is distinguished from Agent retrieval by the 691 HTTP method. Agent creation/update MUST use the POST method. Agent 692 retrieval MUST use the GET method. Agent removal MUST use the DELETE 693 method and specify the Agent name(s) in the query string. 695 All metadata MUST be associated with an Agent. An Agent is created/ 696 modified/retrieved using the "/CDNI/MI/agent" API. The agent API 697 REQUIRES a single query string argument "domain" which specifies the 698 name of the Domain to which the Agent has access. In the case of 699 DELETEs, the agent API also REQUIRES a query string argument "agent" 700 which specifies the name(s) of the Agent(s) to remove, as a comma 701 separated list. 703 A simple XML representation of the information provided to the agent 704 creation/update API or returned from the agent retrieval API is shown 705 below: 707 708 709 710 711 712 713 ... 714 716 3.2.1. Agent Creation 718 The following example creates two new Agents "ucdn" and "dcdn" for 719 the "acme" Domain: 721 POST /CDNI/MI/agent?domain=acme HTTP/1.1 722 Host: host.mi.cdni.example.com 723 Accept: */* 724 Content-Length: 255 725 Content-Type: application/x-www-form-urlencoded 727 728 729 ucdn 730 xxx 731 false 732 733 734 dcdn 735 zzz 736 false 737 738 740 3.2.2. Agent Update 742 The following example updates the "dcdn" Agent in the "acme" Domain: 744 POST /CDNI/MI/agent?domain=acme HTTP/1.1 745 Host: host.mi.cdni.example.com 746 Accept: */* 747 Content-Length: 136 748 Content-Type: application/x-www-form-urlencoded 750 751 752 dcdn 753 yyy 754 true 755 756 758 3.2.3. Agent Retrieval 760 The following example retrieves the updated Agent information for the 761 "acme" Domain: 763 GET /CDNI/MI/agent?domain=acme HTTP/1.1 764 Host: host.mi.cdni.example.com 765 Accept: */* 767 HTTP/1.1 200 OK 768 Content-Length: 254 769 Connection: close 770 Content-Type: text/xml 772 773 774 ucdn 775 xxx 776 false 777 778 779 dcdn 780 yyy 781 true 782 783 785 3.2.4. Agent Removal 787 The following example removes the "dcdn" Agent from the "acme" 788 Domain: 790 DELETE /CDNI/MI/agent?domain=acme&agent=dcdn HTTP/1.1 791 Host: host.mi.cdni.example.com 792 Accept: */* 794 3.2.5. Agent Errors 796 Any update or retrieval request with malformed XML SHOULD respond 797 with a 400 Bad Request status code. Ancillary unknown tags MAY be 798 ignored. 800 Any update or retrieval requests for an Agent which does not exist 801 SHOULD respond with a 404 Not Found status code. 803 3.3. Metadata API 805 Metadata creation/update is distinguished from domain retrieval by 806 the HTTP method. Metadata creation/update MUST use the POST method. 807 Metadata retrieval MUST use the GET method. Metadata MUST be removed 808 if the value field is empty (i.e., updating the value to be an empty 809 string MUST force removal of the entire Metadata entry and all 810 associated Base Address entries). 812 The Metadata for a Domain is created/modified/retrieved using the 813 "/CDNI/MI/metadata/" API. The metadata API REQUIRES a single query 814 string argument "domain" which specifies the name of the Domain to 815 which the Metadata being created/modified/retrieved belongs. Two 816 additional OPTIONAL arguments MAY also be provided when retrieving 817 metadata: "name" which specifies the name of the Metadata field to 818 create/modify/retrieve, "uri" which specifies a URI for which the 819 Metadata must apply, and/or "agent" which specifies the agent(s) to 820 which the Metadata is associated, as a comma separated list. The 821 "agent" option MUST only be allowed for agents with full read/write 822 permissions. 824 A simple XML representation of the information provided to the 825 metadata creation/update API or returned from the metadata retrieval 826 API is shown below: 828 829 830 831 832 833 834 835 836 837 838 ... 839 840 841 ... 842 844 3.3.1. Metadata Creation 846 The following example creates a new default Metadata "origin_server" 847 for the "dcdn" and "ucdn" Agents in the "acme" Domain, issued by the 848 "ucdn" Agent: 850 POST /CDNI/MI/metadata?domain=acme HTTP/1.1 851 Host: host.mi.cdni.example.com 852 Accept: */* 853 Authorization: Basic dWNkbjp4eHg= 854 Content-Length: 540 855 Content-Type: application/x-www-form-urlencoded 857 858 859 /* 860 origin_server 861 edge.ucdn.com 862 true 863 864 dcdn 865 866 *.acme.com 867 868 869 870 /* 871 origin_server 872 anvil.acme.com 873 true 874 875 ucdn 876 877 *.acme.com 878 879 880 882 The following example creates three new Metadata "color" for the 883 "dcdn" and "ucdn" Agents in the "acme" Domain, issued by the "ucdn" 884 Agent: 886 POST /CDNI/MI/metadata?domain=acme HTTP/1.1 887 Host: host.mi.cdni.example.com 888 Accept: */* 889 Authorization: Basic dWNkbjp4eHg= 890 Content-Length: 789 891 Content-Type: application/x-www-form-urlencoded 893 894 895 /grass/* 896 color 897 brown 898 false 899 900 dcdn 901 902 *.acme.com 903 904 905 906 /grass/on/the/other/side/* 907 color 908 green 909 true 910 911 dcdn 912 913 *.acme.com 914 915 916 917 /glasses/* 918 color 919 violet 920 false 921 922 dcdn 923 924 *.acme.com 925 926 927 929 3.3.2. Metadata Update 931 The following example updates the "color" Metadata for the 932 "/glasses/*" portion of the "acme" Domain and "dcdn" Agent, issued by 933 the "ucdn" Agent: 935 POST /CDNI/MI/metadata?domain=acme HTTP/1.1 936 Host: host.mi.cdni.example.com 937 Accept: */* 938 Authorization: Basic dWNkbjp4eHg= 939 Content-Length: 273 940 Content-Type: application/x-www-form-urlencoded 942 943 944 /glasses/* 945 color 946 rose 947 true 948 949 dcdn 950 951 *.acme.com 952 953 954 956 3.3.3. Metadata Retrieval 958 The following example retrieves the Metadata for the URI "/grass/on/ 959 this/side" in the "acme" Domain. The request was issued by and the 960 results are filtered for the "dcdn" Agent: 962 GET /CDNI/MI/metadata?domain=acme&uri=/grass/on/this/side HTTP/1.1 963 Host: host.mi.cdni.example.com 964 Accept: */* 965 Authorization: Basic ZGNkbjp5eXk= 967 HTTP/1.1 200 OK 968 Content-Length: 530 969 Connection: close 970 Content-Type: text/xml 972 973 974 /* 975 origin_server 976 edge.ucdn.com 977 true 978 979 dcdn 980 981 *.acme.com 982 983 984 985 /grass/* 986 color 987 brown 988 false 989 990 dcdn 991 992 *.acme.com 993 994 995 997 The following example retrieves all "color" Metadata for the "acme" 998 Domain. The request was issued by and the results are filtered for 999 the "dcdn" Agent: 1001 GET /CDNI/MI/metadata?domain=acme&name=color HTTP/1.1 1002 Host: host.mi.cdni.example.com 1003 Accept: */* 1004 Authorization: Basic ZGNkbjp5eXk= 1006 HTTP/1.1 200 OK 1007 Content-Length: 786 1008 Connection: close 1009 Content-Type: text/xml 1011 1012 1013 /grass/* 1014 color 1015 brown 1016 false 1017 1018 dcdn 1019 1020 *.acme.com 1021 1022 1023 1024 /grass/on/the/other/side/* 1025 color 1026 green 1027 true 1028 1029 dcdn 1030 1031 *.acme.com 1032 1033 1034 1035 /glasses/* 1036 color 1037 rose 1038 true 1039 1040 dcdn 1041 1042 *.acme.com 1043 1044 1045 1047 The following example retrieves all Metadata for the "acme" Domain. 1048 The request was issued by the "ucdn" Agent but includes Metadata for 1049 both the "ucdn" and "dcdn" Agents: 1051 GET /CDNI/MI/metadata?domain=acme&agent=ucdn,dcdn HTTP/1.1 1052 Host: host.mi.cdni.example.com 1053 Accept: */* 1054 Authorization: Basic dWNkbjp4eHg= 1056 HTTP/1.1 200 OK 1057 Content-Length: 1301 1058 Connection: close 1059 Content-Type: text/xml 1061 1062 1063 /* 1064 origin_server 1065 edge.ucdn.com 1066 true 1067 1068 dcdn 1069 1070 *.acme.com 1071 1072 1073 1074 /* 1075 origin_server 1076 anvil.acme.com 1077 true 1078 1079 ucdn 1080 1081 *.acme.com 1082 1083 1084 1085 /grass/* 1086 color 1087 brown 1088 false 1089 1090 dcdn 1091 1092 *.acme.com 1093 1094 1095 1096 /grass/on/the/other/side/* 1097 color 1098 green 1099 true 1100 1101 dcdn 1102 1103 *.acme.com 1104 1105 1106 1107 /glasses/* 1108 color 1109 rose 1110 true 1111 1112 dcdn 1113 1114 *.acme.com 1115 1116 1117 1119 3.3.4. Metadata Removal 1121 The following example removes the default "origin_server" Metadata 1122 for the "dcdn" Agent in the "acme" Domain by setting the value to an 1123 empty string, issued by the "ucdn" Agent: 1125 POST /CDNI/MI/metadata?domain=acme HTTP/1.1 1126 Host: host.mi.cdni.example.com 1127 Accept: */* 1128 Authorization: Basic dWNkbjp4eHg= 1129 Content-Length: 141 1130 Content-Type: application/x-www-form-urlencoded 1132 1133 1134 /* 1135 origin_server 1136 1137 dcdn 1138 1139 1141 3.3.5. Metadata Errors 1143 For any update or retrieval request with malformed XML, the MI SHOULD 1144 respond with a 400 Bad Request status code. Ancillary unknown tags 1145 MAY be ignored. 1147 For any update or retrieval request for a uri/name/domain_id tuple 1148 which does not exist, the MI SHOULD respond with a 404 Not Found 1149 status code. 1151 For any request which lacks a valid Agent authorization, the MI MUST 1152 respond with a 401 Unauthorized status code. This includes Agents 1153 with valid credentials, but who are marked as read_only and have 1154 requested Metadata associated with an alternate Agent through the 1155 specification of an "agent" query string parameter. 1157 For any request which results in Metadata with an expired TTL, and 1158 for which an update cannot be retrieved from an upstream MI, the MI 1159 MUST respond to with a 500 Internal Server status code. 1161 3.3.6. Metadata Prepositioning 1163 The metadata creation/modification/removal APIs discussed above 1164 SHOULD only be used by uCDNs to preposition metadata in dCDNs. dCDNs 1165 SHOULD NOT modify metadata dictated by the uCDN. dCDNs SHOULD only be 1166 assigned Agents with read_only access and SHOULD NOT have access to 1167 uCDN Domain or Agent APIs (restricted through the use of different 1168 SSL client authentication certificates, as described in the Security 1169 Considerations section). 1171 4. Metadata Definitions 1173 This section defines a base set of Metadata which SHOULD be supported 1174 by all CDNI implementations. 1176 4.1. Origin Server 1178 Content which is not pre-positioned must be acquired by the CDN from 1179 an origin server. The origin server Metadata specifies the base URL 1180 to which the content request URI may be appended in order to acquire 1181 the content. The origin server Metadata is defined as having the 1182 name "origin_server", with valid values containing a comma separated 1183 list of base URLs, and the mandatory flag set to false: 1185 name: origin_server 1186 value: 1187 mandatory: false 1189 In some cases, multiple non-load balanced origin servers may be 1190 available for content acquisition. The origin server Metadata SHOULD 1191 support an unprioritized comma separate list of base URL values. 1193 Note: The origin list Metadata is not mandatory, since, if the 1194 content cannot be acquired, there is no threat of unauthorized 1195 content distribution. Other Metadata or content pre-positioning may 1196 negate the need for origin server Metadata. 1198 4.2. Activation Time 1200 Content may be pre-positioned in anticipation of demand, however, the 1201 content license may have restrictions on delivery timeframe. The 1202 activation time Metadata specifies the first time at which the 1203 content may be delivered. The activation time Metadata is defined as 1204 having the name "activation_time", with valid timestamp values that 1205 MUST conform to RFC3339 [RFC3339], and the mandatory flag set to 1206 true: 1208 name: activation_time 1209 value: 1210 mandatory: true 1212 If the activation time Metadata is set and the current time is less 1213 than the specified activation time, the CDN MUST respond to requests 1214 for that content with a 403 Forbidden status code (or equivalent for 1215 the given non-HTTP request protocol). 1217 4.3. Deactivation Time 1219 Content may be pre-positioned in anticipation of demand, however, the 1220 content license may have restrictions on delivery timeframe. The 1221 deactivation time Metadata specifies the last time at which the 1222 content may be delivered. The deactivation time Metadata is defined 1223 as having the name "deactivation_time", with valid timestamp values 1224 that MUST conform to RFC3339 [RFC3339], and the mandatory flag set to 1225 true: 1227 name: deactivation_time 1228 value: 1229 mandatory: true 1231 If the deactivation time Metadata is set and the current time is 1232 greater than the specified activation time, the CDN MUST respond to 1233 requests for that content with a 403 Forbidden status code (or 1234 equivalent for the given non-HTTP request protocol). 1236 4.4. Administrative Disable 1238 It is sometimes necessary to temporarily disable the distribution of 1239 certain media (e.g., inappropriate content, irregular access 1240 patterns, etc.) within a set accessibility period (i.e., the 1241 activation/deactivation time range). The administrative disable 1242 Metadata instructs the CDN not to deliver the specified content under 1243 any circumstances. The administrative disable Metadata is defined as 1244 having the name "admin_disable", with two valid values "true" and 1245 "false", and the mandatory flag set to true: 1247 name: admin_disable 1248 value: [true | false] 1249 mandatory: true 1251 If the administrative disable Metadata is set to "true", the CDN MUST 1252 respond to requests for that content with a 403 Forbidden status code 1253 (or equivalent for the given non-HTTP request protocol). 1255 4.5. Delegation Disable 1257 CSPs may wish to prevent cascading CDNs to enforce licensing 1258 restrictions. The delegation disable Metadata instructs the CDN not 1259 to delegate requests for the specified content to any dCDNs under any 1260 circumstances. The delegation disable Metadata is defined as having 1261 the name "delegate_disable", with two valid values "true" and 1262 "false", and the mandatory flag set to true: 1264 name: delegate_disable 1265 value: [true | false] 1266 mandatory: true 1268 If the delegation disable Metadata is set to "true", the CDN MUST 1269 either service the content requests itself or respond to requests for 1270 that content with a 504 Server Busy status code (or equivalent for 1271 the given non-HTTP request protocol). 1273 4.6. Footprint Filter 1275 CSPs often purchase rights to content which are only valid when 1276 accessed from certain locations (e.g., within a given country or 1277 through a given access network). The footprint filter Metadata 1278 provides a list of valid source IP subnets from which content 1279 requests may be accepted. The footprint filter Metadata is defined 1280 as having the name "footprint", with valid values containing a comma 1281 separated list of IP subnet definitions, and the mandatory flag set 1282 to true: 1284 name: footprint 1285 value: [, ]... 1286 mandatory: true 1288 If the footprint filter Metadata is set and the source address of a 1289 requesting client does not match any of the IP subnets listed, the 1290 CDN MUST respond to the content request with a 403 Forbidden status 1291 code (or equivalent for the given non-HTTP request protocol). 1293 4.7. HTTP Header Filter 1295 CSPs often desire the ability to filter requests based on the 1296 existence of specific HTTP header fields and values (e.g., User-Agent 1297 headers for device detection or custom headers inserted by client- 1298 side applications). The HTTP header filter Metadata provides a list 1299 of HTTP header names and values which must be verified. The HTTP 1300 header filter Metadata is defined as having the name "http_headers", 1301 with valid values containing a comma separated list of HTTP header 1302 names and regular expression matching criteria definitions, and the 1303 mandatory flag set to true: 1305 name: http_headers 1306 value: : [, :]... 1307 mandatory: true 1309 If the HTTP header filter Metadata is set and the HTTP headers of the 1310 content request do not match all of the filters specified, the CDN 1311 MUST respond to the content request with a 403 Forbidden status code 1312 (or equivalent for the given non-HTTP request protocol). 1314 4.8. Protocol Filter 1316 Though content is typically only accessible using specific a protocol 1317 (e.g., HTTP, RTMP, or RTSP), a CSP may wish to explicitly allow/ 1318 disallow access to certain content for a given protocol. The 1319 protocol filter Metadata provides a list of allowed protocols via 1320 which content may be delivered. The protocol filter Metadata is 1321 defined as having the name "protocol", with valid values containing a 1322 comma separate list of protocol strings, and the mandatory flag set 1323 to true: 1325 name: protocols 1326 value: [, ]... 1327 mandatory: true 1329 If the protocol filter Metadata is set and the request protocol does 1330 not match any protocol in the list, the CDN MUST respond to the 1331 content request with a 403 Forbidden status code (or equivalent for 1332 the given non-HTTP request protocol). 1334 4.9. SSL Required 1336 CSPs which require delivery privacy may require dCDNs to support the 1337 same SSL configurations which were applied to the uCDN. The SSL 1338 required Metadata expresses the requirement to enforce SSL on content 1339 request connections and provides the necessary key and certificate 1340 information required for server authentication. The SSL required 1341 Metadata is defined as having the name "ssl_required", with valid 1342 values containing two URLs (comma separated) which point to the key 1343 and certificate, respectively, and the mandatory flag set to true: 1345 name: ssl_required 1346 value: , 1347 mandatory: true 1349 If the SSL required Metadata is set and the request is not received 1350 over an SSL channel, the CDN MUST respond to the content request with 1351 a 403 Forbidden status code (or equivalent for the given non-HTTP 1352 request protocol). 1354 Note: Retrieval of server key and certificate information SHOULD be 1355 performed in a secure manner. Retrieval could be implemented through 1356 the CDNI MI, however, this is not required. 1358 4.10. SSL Client Authentication Required 1360 CSPs which require client authentication may require dCDNs to support 1361 a SSL client authentication configuration which was applied to the 1362 uCDN. The SSL client authentication required Metadata expresses the 1363 requirement to enforce SSL client authentication on content requests 1364 and provides the necessary certificate authority (CA) information for 1365 authenticating clients. The SSL client authentication required 1366 Metadata is defined as having the name "ssl_auth_required", with 1367 valid values containing a single URL which points to the CA 1368 certificate to be used in client verification, and the mandatory flag 1369 set to true: 1371 name: ssl_auth_required 1372 value: 1373 mandatory: true 1375 If the SSL client authentication required Metadata is set and the 1376 client certificate cannot be verified using the CA certificate, the 1377 CDN MUST respond with a handshake_failure alert. 1379 4.11. URL Hash 1381 TBD. 1383 [Ed. Note: There are many proprietary URL hashing techniques in use 1384 today with varying timestamp formats, query string parameter names, 1385 hashing algorithm combinations, etc. A generic definition of URL 1386 hashing algorithm parameters, capable of supporting all algorithms 1387 would be best.] 1389 5. IANA Considerations 1391 This memo includes no request to IANA. 1393 6. Security Considerations 1395 There are a number of security concerns associated with the MI as 1396 Metadata may be used to influence CDNI request routing. Metadata may 1397 describe content acquisition parameters or content security 1398 restrictions. Altering Metadata or inhibiting Metadata discovery may 1399 impact content distribution. Some MI concerns include: 1401 o intercepting and discarding Metadata requests to prevent content 1402 acquisition may be used as a denial of service attack, 1404 o altering content acquisition Metadata to prevent content 1405 acquisition may be used as a denial of service attack, and 1407 o spoofing content security Metadata to disable delivery 1408 restrictions may be used to circumvent rights management. 1410 To combat these concerns, unauthorized access to the MI MUST be 1411 prevented. The use of SSL with client authentication SHOULD be used 1412 for all MI APIs. Deployments in controlled environments where 1413 physical security and IP address white-listing is employed MAY choose 1414 not to use SSL. Different client authentication certificates SHOULD 1415 be used to protect access to Domain and Agent APIs, as well as uCDN 1416 access to the Metadata API, differently from dCDN access to the 1417 Metadata API. Deployments where uCDNs and dCDNs are mutually trusted 1418 entities (e.g., when uCDNs and dCDNs are controlled by the same 1419 corporate organization) MAY choose to use a single client 1420 authentication certificate. 1422 7. Acknowledgements 1424 The authors would like to thank Daniel Biagini and the CDNI WG 1425 community for their helpful reviews and comments. 1427 8. References 1429 8.1. Normative References 1431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1432 Requirement Levels", BCP 14, RFC 2119, March 1997. 1434 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1435 Timestamps", RFC 3339, July 2002. 1437 8.2. Informative References 1439 [I-D.davie-cdni-framework] 1440 Davie, B., Ed. and L. Peterson, Ed., "Framework for CDN 1441 Interconnection draft-davie-cdni-framework-00", July 2011. 1443 [I-D.ietf-cdni-requirements] 1444 Leung, K. and Y. Lee, "Content Distribution Network 1445 Interconnection (CDNI) Requirements 1446 draft-ietf-cdni-requirements-01", October 2011. 1448 [I-D.ietf-cdni-use-cases] 1449 Bertrand, G., Stephan, E., Watson, G., Burbridge, T., 1450 Eardley, P., and K. Ma, "Use Cases for Content Delivery 1451 Network Interconnection draft-ietf-cdni-use-cases-00", 1452 September 2011. 1454 Author's Address 1456 Kevin J. Ma 1457 Azuki Systems, Inc. 1458 43 Nagog Park 1459 Acton, MA 01720 1460 USA 1462 Phone: +1 978-844-5100 1463 Email: kevin.ma@azukisystems.com