Network Working Group K. Ma Internet-Draft Azuki Systems, Inc. Intended status: Standards Track October 7, 2011 Expires: April 9, 2012 Content Distribution Network Interconnection (CDNI) Metadata Interface draft-ma-cdni-metadata-00 Abstract Content publishers (CPs) often use multiple Content Delivery Networks (CDNs) to deliver content to consumers. Though existing interactions between CPs and individual CDNs are beyond the scope of CDN interconnection (CDNI), it is important to understand the management capabilities and features available with existing non-interconnected multi-CDN deployments. Before migrating to CDNI, CPs must first assess the suitability of CDNI as a replacement for their existing non-interconnected multi-CDN deployments. CDN feature configuration and capability advertisement and enforcement is likely to occur through the CDNI metadata interface (MI). This document describes an approach to implementing the CDNI MI through the use of an extensible metadata model and a light-weight HTTP-based API. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 9, 2012. Copyright Notice Ma Expires April 9, 2012 [Page 1] Internet-Draft CDNI Metadata October 2011 Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Ma Expires April 9, 2012 [Page 2] Internet-Draft CDNI Metadata October 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 2. CDNI Metadata Data Model . . . . . . . . . . . . . . . . . . . 6 2.1. Domain Table . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Hostname Table . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Agent Table . . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Metadata Table . . . . . . . . . . . . . . . . . . . . . . 9 2.4.1. Hierarchical Metadata . . . . . . . . . . . . . . . . 10 3. CDNI Metadata Protocol . . . . . . . . . . . . . . . . . . . . 11 3.1. Domain API . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.1. Domain Creation . . . . . . . . . . . . . . . . . . . 13 3.1.2. Domain Update . . . . . . . . . . . . . . . . . . . . 13 3.1.3. Domain Retrieval . . . . . . . . . . . . . . . . . . . 14 3.1.4. Domain Removal . . . . . . . . . . . . . . . . . . . . 14 3.1.5. Domain Errors . . . . . . . . . . . . . . . . . . . . 15 3.2. Agent API . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.1. Agent Creation . . . . . . . . . . . . . . . . . . . . 16 3.2.2. Agent Update . . . . . . . . . . . . . . . . . . . . . 16 3.2.3. Agent Retrieval . . . . . . . . . . . . . . . . . . . 16 3.2.4. Agent Removal . . . . . . . . . . . . . . . . . . . . 17 3.2.5. Agent Errors . . . . . . . . . . . . . . . . . . . . . 17 3.3. Metadata API . . . . . . . . . . . . . . . . . . . . . . . 18 3.3.1. Metadata Creation . . . . . . . . . . . . . . . . . . 18 3.3.2. Metadata Update . . . . . . . . . . . . . . . . . . . 20 3.3.3. Metadata Retrieval . . . . . . . . . . . . . . . . . . 21 3.3.4. Metadata Removal . . . . . . . . . . . . . . . . . . . 23 3.3.5. Metadata Errors . . . . . . . . . . . . . . . . . . . 24 4. Metadata Definitions . . . . . . . . . . . . . . . . . . . . . 24 4.1. Global Metadata . . . . . . . . . . . . . . . . . . . . . 24 4.2. Content Publisher Metadata . . . . . . . . . . . . . . . . 24 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 Ma Expires April 9, 2012 [Page 3] Internet-Draft CDNI Metadata October 2011 1. Introduction The use cases described in the CDNI use case document [I-D.bertrand-cdni-use-cases] provide motivational use cases for CDN interconnection (CDNI). They describe reasons and situations where CDNI provides a benefit to CDN vendors as well as content service providers (CSPs). Additional use cases exist which describe how CDNs are used today, however, these use cases often involve specific features (e.g., customized content transformations, content security, client authentication and filtering, content acquisition optimization and redundancy, etc.) which are beyond the scope of CDNI. Though the features themselves are not relevant to CDNI, the ability to support those features or enforce policies related to those features in a generic and extensible manner should be considered when designing CDNI interfaces. The ability to support feature parity with existing deployment models (i.e., non-CDNI-based CDN federation) may help to remove barriers to CDNI adoption. Though certain interfaces are out of scope of CDNI, e.g.: o upstream CDN (uCDN) configuration by the CP o uCDN content acquisition o uCDN content delivery o downstream CDN (dCDN) content acquisition o end user (EU) content acquisition o third party workflow management o third party request routing An awareness of these interfaces and an understanding of the restrictions which they may impose on CDNI request routing is useful for understanding the needs of the CDNI metadata interface (MI). As described in the "Dynamic CDNI Metadata Acquisition Example" section in the CDNI framework document [I-D.davie-cdni-framework], upon receiving a request routing interface (RRI) request, the MI MAY be used to retrieve metadata that is "considered" before responding to the RRI request. To that end, the MI MUST define a deterministic method for handling metadata processing. Though the definition and interpretation of any individual piece of metadata is beyond the scope of CDNI, a well-defined method for how to respond to a RRI request when any unknown metadata value is encountered MUST be supported. Ma Expires April 9, 2012 [Page 4] Internet-Draft CDNI Metadata October 2011 This document describes a simple data model for representing CDNI metadata and a simple protocol for creating and retrieving CDNI metadata in an opaque manner. The term opaque, in this case, should be understood to mean: without understanding the underlying meaning or interpretation of the metadata being represented. The metadata model and retrieval protocol SHOULD be completely independent of the definition of individual metadata values. The metadata model and retrieval protocol MUST also define default behaviors for dealing with metadata processing errors. The document defines a list of metadata which are likely applicable to a broad range of CDNI deployments. The document also provides a separate list of metadata which are likely to be desirable to content publishers (CPs). This document is not intended to suggest that any additional interfaces or requirements are needed beyond those already specified in the CDNI requirements document [I-D.lefaucheur-cdni-requirements], nor is this document intended to suggest that any out of scope interfaces or content publisher feature functionality should be brought into scope. The metadata examples provided are intended only to illustrate possible features that interconnected CDNs may wish to support and the extensibility of the metadata model to handle those situations. 1.1. Terminology [Ed. insert terminology reference] 1.2. Abbreviations o CDN: Content Distribution Network o uCDN: Upstream Content Distribution Network o dCDN: Downstream Content Distribution Network o CDNI: Content Distribution Network Interconnection o CP: Content Publisher o CSP: Content Service Provider o EU: End User o NSP: Network Service Provider o RRI: Request Routing Interface o MI: Metadata Interface Ma Expires April 9, 2012 [Page 5] Internet-Draft CDNI Metadata October 2011 2. CDNI Metadata Data Model The simple data model is shown in Figure 1 below. It includes a top level Domain object which describes the site(s) to which metadata is associated. The term site, in this case, should be understood to mean a collection of related content assets access through a single portal or Web-site. The Domain is described by one or more Hostnames through which the site is accessed and which SHOULD be recognized when processing content requests. The Domain is also associated with zero or more opaque Metadata objects. The Metadata objects are each associated with a URI within the Domain and accessible through any of the Hostnames and accessed using URI prefix matching to allow for hierarchical associations between individual Metadata and sets of Metadata. Each Domain is also associated with one or more Agent objects. Agents represent entities which require access to metadata (e.g., CPs or dCDNs). An Agent is associated with each Metadata entry allowing different Metadata values to be returned to different Agents. +----------+ | | 1 | Agent +---------------+ | | | +----+-----+ | | 1..* | | | | 1 | 1 +----+-----+ +----+-----+ | | 1 0..* | | | Domain +----------+ Metadata | | | | | +----+-----+ +----------+ | 1 | | 1..* +----+-----+ | | | Hostname | | | +----------+ Figure 1: CDNI Metadata Data Model The following sections describe an example implementation of the metadata scheme described above using a standard SQL database. Ma Expires April 9, 2012 [Page 6] Internet-Draft CDNI Metadata October 2011 2.1. Domain Table The Domain object contains basic information related to the site being described. The example shown contains a primary key index and a unique name for the site. An OPTIONAL site description (e.g., a textual description of the site and its content) and site provider (e.g., the name of the CP or CSP which owns the content) information is also included. CREATE TABLE "domain" ("domain_id" serial primary key, "name" character varying(255) NOT NULL, "provider" character varying(255), "description" character varying(4095)); CREATE UNIQUE INDEX index_domain ON domain (name); The Domain is the central object for binding metadata. The example Domain shown below highlights the descriptive nature of the Domain object: domain_id: 1 name: acme provider: acme rocket-powered products, inc description: fine purveyors of high quality anvils, rubber bands, bird seed, and rocket powered footwear 2.2. Hostname Table The Hostname object contains basic hostname information related to the site being described. The example shown requires a primary key index, a string containing the hostname, and a foreign key reference to the domain to which this Hostname is associated. A uniqueness constraint is imposed on hostname/domain_id pairs to prevent duplicate Hostname entries for a given Domain. CREATE TABLE "hostname" ("hostname_id" serial primary key, "hostname" character varying(255) NOT NULL, "domain_id" integer NOT NULL); CREATE UNIQUE INDEX index_hostname ON hostname (hostname, domain_id); Hostname Table Definition The Hostname objects list the hostnames through which the Domain content may be accessed. The example Hostnames shown below represent two DNS addresses through which the site may be accessed: Ma Expires April 9, 2012 [Page 7] Internet-Draft CDNI Metadata October 2011 hostname_id: 1 hostname: wile.e.coyote.acme.com domain_id: 1 hostname_id: 2 hostname: road.runner.acme.com domain_id: 1 2.3. Agent Table The Agent object contains basic information for authenticating entities which require access to Metadata. The example shown contains a primary key index, a string containing the username, a string containing the password (possibly hashed or encrypted), a boolean value for differentiating between full read/write access (e.g., for CPs) and read only access (e.g., for dCDNs), and a foreign key reference to the domain to which this Agent is associated. A uniqueness constraint is imposed on username/domain_id pairs to prevent duplicate Agent entries for a given Domain. CREATE TABLE "agent" ("agent_id" serial primary key, "username" character varying(255) NOT NULL, "password" character varying(255) NOT NULL, "read_only" boolean DEFAULT false NOT NULL, "domain_id" integer NOT NULL); CREATE UNIQUE INDEX index_agent ON agent (username, domain_id); Hostname Table Definition The Agent objects manage Metadata access rights. The example Agents shown below represent a CP Agent with write privileges and a dCDN Agent with read-only permissions: agent_id: 1 username: acme_cp password: xxx read_only: false domain_id: 1 agent_id: 2 username: acme_dcdn password: yyy read_only: true domain_id: 1 Ma Expires April 9, 2012 [Page 8] Internet-Draft CDNI Metadata October 2011 2.4. Metadata Table The Metadata object contains the actual individual pieces of metadata for the site being described. The example shown contains a primary key index, a string containing the URI(s) to which the metadata applies, a name/value pair of strings which represent the name and value of the Metadata, respectively, as well as a boolean value stating whether or not enforcement of the given Metadata is mandatory. An OPTIONAL ttl value and timeout field are included to support metadata invalidation. The table also contains a foreign key reference to the Domain to which this Metadata is associated and a foreign key reference to the Agent to whom this Metadata is intended. A compound uniqueness constraint is also applied to each uri/name/ domain_id/agent_id tuple to prevent a given Metadata from being ambiguously applied multiple times to the same URI in a given Domain for a given Agent. CREATE TABLE "metadata" ("metadata_id" serial primary key, "uri" character varying(4095) NOT NULL, "name" character varying(255) NOT NULL, "value" character varying(4095) NOT NULL, "mandatory" boolean DEFAULT false NOT NULL, "ttl" integer DEFAULOT 0 NOT NULL, "timeout" timestamp without time zone, "domain_id" integer NOT NULL, "agent_id" integer NOT NULL); CREATE UNIQUE INDEX index_metadata ON metadata (uri, name, domain_id, agent_id); The name/value pair is represented as simple opaque strings. The MI has no understanding of any inherent meaning for the Metadata names or values. Metadata names SHOULD be properly defined and registered, and any implied functionality SHOULD be agreed upon a priori by CDN operators, however, these negotiations are beyond the scope of CDNI. The intent of the mandatory boolean is to identify Metadata that MUST be enforced by all CDNs. If a CDN is unable to understand or is unable to comply with the Metadata, it MUST NOT deliver the content being requests. For dCDNs, the mandatory flag defines how to respond to RRI requests when unknown Metadata is encountered. If Metadata is marked as mandatory, then the dCDN MUST NOT accept the RRI request if it does not know how to process that piece of Metadata. If the MI request resulted from a "recursive" RRI request, then the dCDN MUST return an error to the uCDN; if the MI request resulted from an "iterative" RRI request, then the dCDN MUST respond with a 403 Forbidden status code to the EU. The OPTIONAL ttl value is provided to allow configuration of a Ma Expires April 9, 2012 [Page 9] Internet-Draft CDNI Metadata October 2011 Metadata TTLs. The ttl MUST be specified in seconds and the timeout field SHOULD be populated by the local MI processor and used internally, to prevent the need for clock synchronization between MI processors. The association of each Metadata to an Agent allows different Agents to retrieve different Metadata values for a given URI in the given Domain. This is intended to allow CDNs to separate upstream Metadata from downstream Metadata (e.g., a uCDN content acquisition URL may point to a CP origin, however the content acquisition URL that the dCDN retrieves from the uCDN may point at a surrogate in the uCDN). 2.4.1. Hierarchical Metadata In order to support hierarchical metadata, '/*' SHOULD be allowed as the last part of the URI hierarchy, signifying the application of this Metadata value to all URIs which match this URI prefix. If multiple Metadata are defined with overlapping prefixes, the URI with the longest prefix match MUST be used. The uniqueness constraint on the uri/name/domain_id tuple should allow for unambiguous resolution of Metadata priority. Given the following three Metadata, the value of the color Metadata object is defined four times within the same Domain but for different URIs and Agents. Ma Expires April 9, 2012 [Page 10] Internet-Draft CDNI Metadata October 2011 metadata_id: 1 uri: /* name: color value: blue mandatory: false ttl: 0 domain_id: 1 agent_id: 2 metadata_id: 1 uri: /* name: color value: gold mandatory: false ttl: 0 domain_id: 1 agent_id: 1 metadata_id: 2 uri: /grass/* name: color value: brown mandatory: false ttl: 0 domain_id: 1 agent_id: 2 metadata_id: 3 uri: /grass/on/the/other/side/* name: color value: green mandatory: false ttl: 0 domain_id: 1 agent_id: 2 The default value for the color metadata (signified by the all encompassing URI "/*") is blue for the dCDN Agent and gold for the CP Agent. Alternate colors are associated with requests from the dCDN Agent for URIs that begin with "/grass". By default /grass has a color of brown, except when requesting "/grass/on/the/other/side/" which is green. 3. CDNI Metadata Protocol The Domain, Agent, and Metadata creation/retrieval protocols are defined in the following sections. All use a simple HTTP-based Ma Expires April 9, 2012 [Page 11] Internet-Draft CDNI Metadata October 2011 approach. The protocol, in general, SHOULD be data format agnostic. The examples shown herein use an XML representation for MI requests/ responses, however, other well-defined representations (e.g., JSON) are also acceptable. The protocol shown provides an example of the functionality required to support the data model described in Section 2, however, any protocol which allows for the creation, modification, retrieval, and removal of Domains, Agents, and Metadata could also be acceptable. It is assumed that a well-known hostname to which MI requests should be sent is configured through the CDNI bootstrap data. Bootstrap information is sent through the CDNI control interface, as described in the CDNI requirements document [I-D.lefaucheur-cdni-requirements]. This CDNI MI bootstrap data corresponds to the MI SEED information described in the CDNI framework document [I-D.davie-cdni-framework]. The MI APIs described herein are intended to be serviced by the MI running on that host. The actual entity which processes the requests is inconsequential, as long as it has access to the metadata database. Domain and Agent configurations must exist prior to Metadata creation/retrieval. Domains and Agents MAY be created as a part of an off-line business negotiation process or as a part of the CDNI bootstrapping process. Domains and Agents do not necessarily need to be created dynamically using the APIs described below, however, the APIs are included for completeness. When the Domain and Agent APIs are used, access to the APIs SHOULD be secured using SSL with client authentication as described in the Security Considerations section. New content and Metadata MAY be uploaded at any time. The Metadata API MUST support dynamic creation and modification of Metadata by valid Agents. Though the Metadata API SHOULD also be secured using SSL with client authentication as described in the Security Considerations section, an additional Agent authentication mechanism is REQUIRED to properly filter requests and results. In the examples shown below, HTTP basic authentication is used for Agent authentication, though other methods (e.g., HTTP digest authentication or URL hashing) could also be used. 3.1. Domain API Domain creation/update is distinguished from domain retrieval by the HTTP method. Domain creation/update MUST use the POST method. Domain retrieval MUST use the GET method. The Domain MUST be removed if there are no Hostnames associated with the domain (i.e., removing all the Hostnames from the Domain MUST force the removal of the Domain itself, and all of its associated Agents and Metadata). Ma Expires April 9, 2012 [Page 12] Internet-Draft CDNI Metadata October 2011 All metadata MUST be associated with a Domain. A Domain is created/ modified/retrieved using the "/CDNI/MI/domain" API. The domain API REQUIRES a single query string argument "domain" which specifies the name of the Domain to be created/modified/retrieved. A simple XML representation of the information provided to the domain creation/update API or returned from the domain retrieval API is shown below: ... 3.1.1. Domain Creation The following example creates a new Domain "acme": POST /CDNI/MI/domain?domain=acme HTTP/1.1 Host: host.mi.cdni.example.com Accept: */* Content-Length: 185 Content-Type: application/x-www-form-urlencoded acme acme wec.acme.com rr.acme.com 3.1.2. Domain Update The following example updates the "acme" Domain: Ma Expires April 9, 2012 [Page 13] Internet-Draft CDNI Metadata October 2011 POST /CDNI/MI/domain?domain=acme HTTP/1.1 Host: host.mi.cdni.example.com Accept: */* Content-Length: 335 Content-Type: application/x-www-form-urlencoded acme rocket-powered products, inc fine purveyors of high quality anvils, rubber bands, bird seed, and rocket powered footwear wile.e.coyote.acme.com road.runner.acme.com 3.1.3. Domain Retrieval The following example retrieves the updated "acme" Domain information: GET /CDNI/MI/domain?domain=acme HTTP/1.1 Host: host.mi.cdni.example.com Accept: */* HTTP/1.1 200 OK Content-Length: 335 Connection: close Content-Type: text/xml acme rocket-powered products, inc fine purveyors of high quality anvils, rubber bands, bird seed, and rocket powered footwear wile.e.coyote.acme.com road.runner.acme.com The MI MAY support bulk retrieval of Domains through the use of a comma separated list of Domain names in the domain query string parameter. 3.1.4. Domain Removal The following example removes the "acme" Domain by updating the Domain to remove all Hostnames: Ma Expires April 9, 2012 [Page 14] Internet-Draft CDNI Metadata October 2011 POST /CDNI/MI/domain?domain=acme HTTP/1.1 Host: host.mi.cdni.example.com Accept: */* Content-Length: 34 Content-Type: application/x-www-form-urlencoded 3.1.5. Domain Errors Any update or retrieval request with malformed XML SHOULD respond with a 400 Bad Request status code. Ancillary unknown tags MAY be ignored. Any update or retrieval request for a Domain which does not exist SHOULD respond with a 404 Not Found status code. 3.2. Agent API Agent creation/update is distinguished from Agent retrieval by the HTTP method. Agent creation/update MUST use the POST method. Agent retrieval MUST use the GET method. The Agent MUST be removed if the password field is empty (i.e., updating the password to be an empty string MUST force removal of the entire Agent object and all of it's associated Metadata). All metadata MUST be associated with an Agent. An Agent is created/ modified/retrieved using the "/CDNI/MI/agent" API. The agent API REQUIRES a single query string argument "domain" which specifies the name of the Domain to which the Agent has access. A simple XML representation of the information provided to the agent creation/update API or returned from the agent retrieval API is shown below: ... Ma Expires April 9, 2012 [Page 15] Internet-Draft CDNI Metadata October 2011 3.2.1. Agent Creation The following example creates two new Agents "acme_cp" and "acme_dcdn" for the "acme" Domain: POST /CDNI/MI/agent?domain=acme HTTP/1.1 Host: host.mi.cdni.example.com Accept: */* Content-Length: 253 Content-Type: application/x-www-form-urlencoded acme_cp xxx false acme_dcdn zzz false 3.2.2. Agent Update The following example updates the "acme_dcdn" Agent in the "acme" Domain: POST /CDNI/MI/agent?domain=acme HTTP/1.1 Host: host.mi.cdni.example.com Accept: */* Content-Length: 136 Content-Type: application/x-www-form-urlencoded acme_dcdn yyy true 3.2.3. Agent Retrieval The following example retrieves the updated Agent information for the "acme" Domain: Ma Expires April 9, 2012 [Page 16] Internet-Draft CDNI Metadata October 2011 GET /CDNI/MI/agent?domain=acme HTTP/1.1 Host: host.mi.cdni.example.com Accept: */* HTTP/1.1 200 OK Content-Length: 252 Connection: close Content-Type: text/xml acme_cp xxx false acme_dcdn yyy true 3.2.4. Agent Removal The following example removes the "acme_dcdn" Agent from the "acme" Domain by setting the password to an empty string: POST /CDNI/MI/agent?domain=acme HTTP/1.1 Host: host.mi.cdni.example.com Accept: */* Content-Length: 91 Content-Type: application/x-www-form-urlencoded acme_dcdn 3.2.5. Agent Errors Any update or retrieval request with malformed XML SHOULD respond with a 400 Bad Request status code. Ancillary unknown tags MAY be ignored. Any update or retrieval requests for an Agent which does not exist SHOULD respond with a 404 Not Found status code. Ma Expires April 9, 2012 [Page 17] Internet-Draft CDNI Metadata October 2011 3.3. Metadata API Metadata creation/update is distinguished from domain retrieval by the HTTP method. Metadata creation/update MUST use the POST method. Metadata retrieval MUST use the GET method. Metadata MUST be removed if the value field is empty (i.e., updating the value to be an empty string MUST force removal of the entire Metadata entry). The Metadata for a Domain is created/modified/retrieved using the "/CDNI/MI/metadata/" API. The metadata API REQUIRES a single query string argument "domain" which specifies the name of the Domain to which the Metadata being created/modified/retrieved belongs. Two additional OPTIONAL arguments MAY also be provided when retrieving metadata: "name" which specifies the name of the metadata field to create/modify/retrieve and "uri" which specifies a URI for which the metadata must apply. A simple XML representation of the information provided to the metadata creation/update API or returned from the metadata retrieval API is shown below: ... 3.3.1. Metadata Creation The following example creates a new default Metadata "origin" for the "acme_dcdn" and "acme_cp" Agents in the "acme" Domain, issued by the "acme_cp" Agent: Ma Expires April 9, 2012 [Page 18] Internet-Draft CDNI Metadata October 2011 POST /CDNI/MI/metadata?domain=acme HTTP/1.1 Host: host.mi.cdni.example.com Accept: */* Authorization: Basic YWNtZV9jcDp4eHg= Content-Length: 382 Content-Type: application/x-www-form-urlencoded /* origin edge.ucdn.com true acme_dcdn /* origin anvil.acme.com true acme_cp The following example creates three new Metadata "color" for the "acme_dcdn" and "acme_cp" Agents in the "acme" Domain, issued by the "acme_cp" Agent: Ma Expires April 9, 2012 [Page 19] Internet-Draft CDNI Metadata October 2011 POST /CDNI/MI/metadata?domain=acme HTTP/1.1 Host: host.mi.cdni.example.com Accept: */* Authorization: Basic YWNtZV9jcDp4eHg= Content-Length: 576 Content-Type: application/x-www-form-urlencoded /grass/* color brown false acme_dcdn /grass/on/the/other/side/* color green true acme_dcdn /glasses/* color violet false acme_dcdn 3.3.2. Metadata Update The following example updates the "color" Metadata for the "/glasses/*" portion of the "acme" Domain and "acme_dcdn" Agent, issued by the "acme_cp" Agent: Ma Expires April 9, 2012 [Page 20] Internet-Draft CDNI Metadata October 2011 POST /CDNI/MI/metadata?domain=acme HTTP/1.1 Host: host.mi.cdni.example.com Accept: */* Authorization: Basic YWNtZV9jcDp4eHg= Content-Length: 202 Content-Type: application/x-www-form-urlencoded /glasses/* color rose true acme_dcdn 3.3.3. Metadata Retrieval The following example retrieves the Metadata for the URI "/grass/on/ this/side" in the "acme" Domain. The request was issued by and the results are filtered for the "acme_dcdn" Agent: Ma Expires April 9, 2012 [Page 21] Internet-Draft CDNI Metadata October 2011 GET /CDNI/MI/domain?domain=acme&uri=/grass/on/this/side HTTP/1.1 Host: host.mi.cdni.example.com Accept: */* Authorization: Basic YWNtZV9kY2RuOnl5eQ== HTTP/1.1 200 OK Content-Length: 381 Connection: close Content-Type: text/xml /* origin edge.ucdn.com true acme_dcdn /grass/* color brown false acme_dcdn The following example retrieves all "color" Metadata for the "acme" Domain. The request was issued by and the results are filtered for the "acme_dcdn" Agent: Ma Expires April 9, 2012 [Page 22] Internet-Draft CDNI Metadata October 2011 GET /CDNI/MI/domain?domain=acme&name=color HTTP/1.1 Host: host.mi.cdni.example.com Accept: */* Authorization: Basic YWNtZV9kY2RuOnl5eQ== HTTP/1.1 200 OK Content-Length: 573 Connection: close Content-Type: text/xml /grass/* color brown false acme_dcdn /grass/on/the/other/side/* color green true acme_dcdn /glasses/* color rose true acme_dcdn 3.3.4. Metadata Removal The following example removes the default "origin" Metadata for the"acme_dcdn" Agent in the "acme" Domain by setting the value to an empty string, issued by the "acme_cp" Agent: Ma Expires April 9, 2012 [Page 23] Internet-Draft CDNI Metadata October 2011 POST /CDNI/MI/metadata?domain=acme HTTP/1.1 Host: host.mi.cdni.example.com Accept: */* Authorization: Basic YWNtZV9jcDp4eHg= Content-Length: 134 Content-Type: application/x-www-form-urlencoded /* origin acme_dcdn 3.3.5. Metadata Errors Any update or retrieval request with malformed XML SHOULD respond with a 400 Bad Request status code. Ancillary unknown tags MAY be ignored. Any update or retrieval request for a uri/name/domain_id tuple which does not exist SHOULD respond with a 404 Not Found status code. Any request which lacks a valid Agent authorization MUST respond with a 401 Unauthorized status code. 4. Metadata Definitions This section defines an initial set of CDNI Metadata. 4.1. Global Metadata This section defines a base set of Metadata which SHOULD be supported by all CDNI implementations. TBD. 4.2. Content Publisher Metadata This section defines an OPTIONAL set of Metadata, useful to CP deployments, which MAY be supported by CDNI implementations. TBD. Ma Expires April 9, 2012 [Page 24] Internet-Draft CDNI Metadata October 2011 5. IANA Considerations This memo includes no request to IANA. 6. Security Considerations There are a number of security concerns associated with the MI. Metadata may be used to influence CDNI request routing. Metadata may describe content acquisition parameters or content security restrictions. Altering Metadata or inhibiting Metadata discovery may impact content distribution. Some MI concerns include: o Intercepting and discarding Metadata requests to prevent content acquisition may be used as a denial of service attack. o Altering content acquisition Metadata to prevent content acquisition may be used as a denial of service attack. o Spoofing content security Metadata to disable delivery restrictions may be used to circumvent rights management. To combat these concerns, unauthorized access to the MI MUST be prevented. The use of SSL with client authentication SHOULD be used for all MI APIs. Deployments in controlled environments where physical security and IP address white-listing is employed MAY choose not to use SSL. 7. Acknowledgements The authors would like to thank Daniel Biagini, Gilles Bertrand, and Raj Nair for their helpful reviews and comments. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.bertrand-cdni-use-cases] Bertrand, G., Stephan, E., Watson, G., Burbridge, T., Eardley, P., and K. Ma, "Use Cases for Content Delivery Network Interconnection draft-bertrand-cdni-use-cases-02", Ma Expires April 9, 2012 [Page 25] Internet-Draft CDNI Metadata October 2011 July 2011. [I-D.davie-cdni-framework] Davie, B., Ed. and L. Peterson, Ed., "Framework for CDN Interconnection draft-davie-cdni-framework-00", July 2011. [I-D.lefaucheur-cdni-requirements] Leung, K., Lee, Y., Le Faucheur, F., Viveganandhan, M., and G. Watson, "Content Distribution Network Interconnection (CDNI) Requirements draft-lefaucheur-cdni-requirements-02", July 2011. Author's Address Kevin J. Ma Azuki Systems, Inc. 43 Nagog Park Acton, MA 01720 USA Phone: +1 978-844-5100 Email: kevin.ma@azukisystems.com Ma Expires April 9, 2012 [Page 26]