Content Distribution Network
Interconnection (CDNI) RequirementsCisco Systems170 West Tasman DriveSan Jose95134CAU.S.A.+1 408 526 5030kleung@cisco.comComcastOne Comcast CenterPhiladelphiaPA19103U.S.A.yiu_lee@cable.comcast.comContent Delivery Networks (CDNs) are frequently used for large-scale
content delivery. As a result, existing CDN providers are scaling up
their infrastructure and many Network Service Providers (NSPs) are
deploying their own CDNs. There is a requirement for interconnecting
standalone CDNs so that their collective CDN footprint can be leveraged
for the end-to-end delivery of content from Content Service Providers
(CSPs) to end users. The Content Distribution Network Interconnection
(CDNI) working group has been chartered to develop an interoperable and
scalable solution for such CDN interconnection.The goal of the present document is to outline the requirements for
the solution and interfaces to be specified by the CDNI working
group. This draft is a work in progress and requirements may be added, modified, or
removed by the working group. The key words "High Priority", "Medium Priority" and "Low Priority" in this document are to be
interpreted in the following way:"High Priority" indicates requirements that are to be supported by the
CDNI interfaces. A requirement is stated as "High Priority" when
it is established by the working group that it can be met without compromising the
targeted schedule for WG deliverables, or when it is established
that specifying a solution without meeting this requirement would
not make sense and would justify re-adjusting the WG schedule, or
both. This is tagged as "[HIGH]"."Medium Priority" indicates requirements that are to be supported by the
CDNI interfaces unless the WG realizes at a later stage
that attempting to meet this requirement would compromise the
overall WG schedule (for example it would involve complexities that
would result in significantly delaying the deliverables). This is tagged as "[MED]"."Low Priority" indicates requirements that are to be supported by the CDNI
interfaces provided that dedicating WG resources to
this work does not prevent addressing "High Priority" and "Medium Priority"
requirements and that attempting to meet this requirement would not
compromise the overall WG schedule. This is tagged as "[LOW]".The volume of video and multimedia content delivered over the
Internet is rapidly increasing and expected to continue doing so in the
future. In the face of this growth, Content Delivery Networks (CDNs)
provide numerous benefits: reduced delivery cost for cacheable content,
improved quality of experience for end users, and increased robustness
of delivery. For these reasons CDNs are frequently used for large-scale
content delivery. As a result, existing CDN providers are scaling up
their infrastructure and many Network Service Providers (NSPs) are
deploying their own CDNs. It is generally desirable that a given content
item can be delivered to an End User regardless of that End User's
location or attachment network. However, the footprint of a given CDN in
charge of delivering a given content may not expand close enough to the
End User's current location or attachment network to realize the cost
benefit and user experience that a more distributed CDN would provide.
This creates a requirement for interconnecting standalone CDNs so that
their collective CDN footprint can be leveraged for the end-to-end
delivery of content from Content Service Providers (CSPs) to End Users.
The Content Distribution Network Interconnection (CDNI) working group
has been chartered to develop an interoperable and scalable solution
for such CDN interconnection. outlines
the problem area that the CDNI working group is chartered to address.
discusses the use
cases for CDN Interconnection. discusses the technology
framework for the CDNI solution and interfaces.The goal of the present document is to document the requirements for
the CDNI solution and interfaces. In order to meet the timelines defined in the working group charter,
the present document categorizes the CDNI requirements as "High Priority",
"Medium Priority", and "Low Priority".This document uses the terminology defined in section 1.1 of .For convenience Figure 1 from illustrating the
CDNI problem area and the CDNI protocols is replicated below.This section identifies generic requirements independent of the
individual CDNI interfaces. Some of those are expected to affect multiple
or all interfaces.[MED] Wherever possible, the CDNI interfaces should reuse or leverage
existing IETF protocols.[HIGH] The CDNI solution shall not require a change, or an upgrade, to
the User Agent to benefit from content delivery through
interconnected CDNs.[HIGH] The CDNI solution shall not require a change, or an upgrade, to
the Content Service Provider to benefit from content delivery through
interconnected CDNs.[HIGH] The CDNI solution shall not require intra-CDN information to be
exposed to other CDNs for effective and efficient delivery of the
content. Examples of intra-CDN information include surrogate
topology, surrogate status, cached content, etc.[HIGH] The CDNI solution shall support delivery to the user agent based
on HTTP . (Note that while delivery
and acquisition "data plane" protocols are out of the CDNI
solution scope, the CDNI solution "control plane" protocols are
expected to participate in enabling, selecting or facilitating
operations of such acquisition and delivery protocols. Hence it is
useful to state requirements on the CDNI solution in terms of
which acquisition and delivery protocols).[HIGH] The CDNI solution shall support acquisition across CDNs based on
HTTP .[LOW] The CDNI solution may support delivery to the user agent based
on protocols other than HTTP.[LOW] The CDNI solution may support acquisition across CDNs based on
protocols other than HTTP.[MED] The CDNI solution should support cascaded CDN redirection (CDN1
redirects to CDN2 that redirects to CDN3) to an arbitrary number
of levels beyond the first level.[MED] The CDNI solution should support an arbitrary topology of
interconnected CDNs (i.e. the CDN topology cannot be restricted to
a tree, a loop-free topology, etc.).[HIGH] The CDNI solution shall prevent looping of any CDNI information
exchange.[HIGH] When making use of third party reference, the CDNI solution
shall consider the potential issues associated with the use of
various format of third-party references (e.g. NAT or IPv4/IPv6
translation potentially breaking third-party references based on
an IP addresses such as URI containing IPv4 or IPv6 address
litterals, split DNS situations potentially breaking third-party
references based on DNS fully qualified domain names) and wherever
possible avoid, minimize or mitigate the associated risks based on
the specifics of the environments where the reference is used
(e.g. likely or unlikely presence of NAT in the path). In
particular, this applies to situations where the CDNI solution
needs to construct and convey uniform resource identifiers for
directing/redirecting a content request, as well as to situations
where the CDNI solution needs to pass on a third party reference
(e.g. to identify a User Agent) in order to allow another entity
to make a more informed decision (e.g. make a more informed
request routing decision by attempting to derive location
information from the third party reference).[LOW] The CDNI solution should support virtualization ...[HIGH] The CDNI solution shall support HTTP Adaptive Bit Rate (ABR) content.The primary purpose of the CDNI Control interface is to initiate the
interconnection across CDNs, bootstrap the other CDNI interfaces and
trigger actions into the Downstream CDN by the Upstream CDN (such as
delete object from caches or trigger pre-positioned content
acquisition). We observe that while the CDNI Control interface is
currently discussed as a single "protocol", further analysis will
determine whether the corresponding requirements are to be realized over
a single interface and protocol, or over multiple interfaces and
protocols.[HIGH] The CDNI Control interface shall allow the Upstream CDN to
request that the Downstream CDN (and, if cascaded CDNs are
supported by the solution, that the potential cascaded Downstream
CDNs) perform the following actions on an object or object set:
Mark an object or set of objects and/or its CDNI metadata as
“stale” and revalidate them before they are
delivered againDelete an object or set of objects and/or its CDNI metadata from the CDN
surrogates and any storage. Only the object(s) and CDNI metadata that
pertain to the requesting Upstream CDN are allowed to be purged.[HIGH] The CDNI Control interface shall allow the Downstream CDN to
report on the completion of these actions (by itself, and if
cascaded CDNs are supported by the solution, by potential cascaded
Downstream CDNs), in a manner appropriate for the action (e.g.
synchronously or asynchronously). The confirmation receipt should
include a success or failure indication. The failure indication is used
if the Downstream CDN cannot delete the content in its storage.[HIGH] The CDNI Control interface shall support initiation and control
by the Upstream CDN of pre-positioned CDNI metadata acquisition by
the Downstream CDN.[MED] The CDNI Control interface should support initiation and control
by the Upstream CDN of pre-positioned content acquisition by the
Downstream CDN.[LOW] The CDNI Control interface may allow a CDN to establish, update
and terminate a CDN interconnection with another CDN whereby one
CDN can act as a Downstream CDN for the other CDN (that acts as an
Upstream CDN).[LOW] The CDNI Control interface may allow control of the CDNI
interconnection between any two CDNs independently for each
direction (i.e. For the direction where CDN1 is the Upstream CDN
and CDN2 is the Downstream CDN, and for the direction where CDN2
is the Upstream CDN and CDN1 is the Downstream CDN).[LOW] The CDNI Control interface may allow bootstrapping of the
Request-Routing interface. For example, this can potentially
include:negotiation of the Request-Routing method (e.g. DNS vs
HTTP, if more than one method is specified)discovery of the Request-Routing protocol endpointsinformation necessary to establish secure communication
between the Request-Routing protocol endpoints.[LOW] The CDNI Control interface may allow bootstrapping of the
CDNI Metadata interface. This information could, for example,
include:discovery of the CDNI Metadata signaling protocol endpointsinformation necessary to establish secure communication
between the CDNI Metadata signaling protocol endpoints.[LOW] The CDNI Control interface may allow bootstrapping of the
Content Acquisition interface. This could, for example, include
exchange and negotiation of the Content Acquisition protocols to
be used across the CDNs (e.g. HTTP, HTTPS, FTP, ATIS C2).[LOW] The CDNI Control interface may allow exchange and negotiation
of delivery authorization mechanisms to be supported across the
CDNs (e.g. URI signature based validation).[LOW] The CDNI Control interface may allow bootstrapping of the
CDNI Logging interface. This information could, for example,
include:discovery of the Logging protocol endpointsinformation necessary to establish secure communication
between the Logging protocol endpointsnegotiation/definition of the log file format and set of
fields to be exported through the Logging protocol, with some
granularity (e.g. On a per content type basis).negotiation/definition of parameters related to transaction
Logs export (e.g., export protocol, file compression, export
frequency, directory).The main function of the Request Routing interface is to allow the
Request-Routing systems in interconnected CDNs to communicate to
facilitate redirection of the request across CDNs.[HIGH] The CDNI Request-Routing interface shall allow the Downstream CDN to
communicate to the Upstream CDN coarse information about the
Downstream CDN ability and/or willingness to handle requests from
the Upstream CDN. For example, this could potentially include a
binary signal (“Downstream CDN ready/not-ready to take additional
requests from Upstream CDN”) to be used in case of excessive
load or failure condition in the Downstream CDN. [MED] The CDNI Request-Routing interface should allow the Downstream
CDN to communicate to the Upstream CDN aggregate information to
facilitate CDN selection during request routing, such as
Downstream CDN capabilities, resources and affinities (i.e.
Preferences or cost). This information could, for example,
include:supported content types and delivery protocolsfootprint (e.g. layer-3 coverage)a set of metrics/attributes (e.g. Streaming bandwidth,
storage resources, distribution and delivery priority)a set of affinities (e.g. Preferences, indication of
distribution/delivery fees)information to facilitate request redirection (e.g.
Reachability information of Downstream CDN Request Routing
system).[Note: Some of this information - such as supported
content types and delivery protocols- may also potentially be
taken into account by the distribution system in the Upstream CDN
for pre-positioning of content and/or metadata in the Downstream
CDN in case of pre-positioned content acquisition and/or
pre-positioned CDNI metadata acquisition.][MED] In the case of cascaded redirection, the
CDNI Request-Routing interface shall allow the Downstream CDN to
also include in the information communicated to the Upstream CDN,
information on the capabilities, resources and affinities of CDNs
to which the Downstream CDN may (in turn) redirect requests
received by the Upstream CDN. In that case, the CDNI
Request-Routing interface shall prevent looping of such information
exchange.[LOW] The CDNI Request-Routing interface may allow the Downstream CDN to
communicate to the Upstream CDN aggregate information on CDNI
administrative limits and policy. This information can be taken
into account by the Upstream CDN Request Routing system in its CDN
Selection decisions. This information could, for example,
include:maximum number of requests redirected by the Upstream CDN
to be served simultaneously by the Downstream CDNmaximum aggregate volume of content (e.g. in Terabytes) to
be delivered by the Downstream CDN over a time period.[HIGH] The CDNI Request-Routing architecture and interface shall support
efficient request-routing for small objects. This may, for
example, call for a mode of operation (e.g. DNS-based request
routing) where freshness and accuracy of CDN/Surrogate selection
can be traded-off against reduced request-routing load (e.g. Via
lighter-weight queries and caching of request-routing
decisions).[HIGH] The CDNI Request-Routing architecture and interface shall support
efficient request-routing for large objects. This may, for
example, call for a mode of operation (e.g. HTTP-based request
routing) where freshness and accuracy of CDN/Surrogate selection
justifies a per-request decision and a per-request CDNI
Request-Routing protocol call.[HIGH] The CDNI Request-Routing architecture shall support recursive
CDNI request routing.[HIGH] The CDNI Request-Routing architecture shall support iterative
CDNI request routing.[MED] In case of detection of a request redirection loop, the CDNI
Request-Routing loop prevention mechanism should allow routing of
the request by avoiding the loop (as opposed to the request loop being simply
interrupted without routing the request).[MED] The CDNI Request-Routing protocol should support a
mechanism allowing enforcment of a limit on the number of
successive CDN redirections for a given request.[LOW] The CDNI Request-Routing protocol may support a
mechanism allowing an Upstream CDN to avoid redirecting a request
to a Downstream CDN if that is likely to result in the total
redirection time exceeding some limit.[HIGH] The CDNI Request-Routing protocol shall allow the Upstream CDN
to include, in the query to the Downstream CDN, the necessary
information to allow the Downstream CDN to process the redirection
query. This could, for example, include:information from which the location of the user-agent that
originated the request can be inferred (e.g. User Agent fully
qualified domain name in case of HTTP-based Request Routing,
DNS Proxy fully qualified domain name in case of DNS-based
Request Routing)requested resource information (e.g. Resource URI in case
of HTTP-based Request Routing, Resource hostname in case of
DNS-based Request Routing)additional available request information (e.g. request
headers in case of HTTP-based Request Routing).[LOW] The CDNI Request-Routing protocol may also allow the Upstream
CDN to convey information pointing to CDNI metadata applicable
(individually or through inheritance) to the requested content.
For illustration, the CDNI metadata pointed to could potentially
include metadata that is applicable to any content, metadata that
is applicable to a content collection (to which the requested
content belongs) and/or metadata that is applicable individually
to the requested content.[HIGH] The CDNI Request-Routing interface shall allow the Downstream CDN
to include the following information in the response to the
Upstream CDN:status code, in particular indicating acceptance or
rejection of request (e.g. Because the Downstream CDN is
unwilling or unable to serve the request). In case of
rejection, an error code is also to be provided, which allows
the Upstream CDN to react appropriately (e.g. Select another
Downstream CDN, or serve the request itself)redirection information (e.g. Resource URI in case of
HTTP-based Request Routing, equivalent of a DNS record in case
of DNS-based Request Routing).The primary function of the CDNI Metadata Distribution interface is to
allow the Distribution system in interconnected CDNs to communicate to
ensure Content Distribution Metadata with inter-CDN scope can be
exchanged across CDNs. We observe that while the CDNI Metadata
Distribution protocol is currently discussed as a single "protocol",
further analysis will determine whether the corresponding requirements
are to be realized over a single interface and protocol, or over
multiple interfaces and protocols. For example, a subset of the CDNI
metadata might be conveyed in-band along with the actual content
acquisition across CDNs (e.g. content MD5 in HTTP header) while another
subset might require an out-of-band interface & protocol (e.g.
geo-blocking information).[HIGH] The CDNI Metadata Distribution interface shall allow the Upstream
CDN to provide the Downstream CDN with content distribution
metadata of inter-CDN scope.[HIGH] The CDNI Metadata Distribution interface shall support exchange
of CDNI metadata for both the dynamic content acquisition model
and the pre-positioning content acquisition model.[HIGH] The CDNI Metadata Distribution interface shall
support a mode where no, or a subset of, the Metadata is initially
communicated to the Downstream CDN along with information about
how/where to acquire the rest of the CDNI Metadata (i.e. Dynamic
CDNI metadata acquisition).[MED] The CDNI Metadata Distribution interface should
support a mode where all the relevant Metadata is initially
communicated to the Downstream CDN (i.e. Pre-positioned CDNI
metadata acquisition).[HIGH] Whether in the pre-positioned content acquisition model or in
the dynamic content acquisition model, the CDNI Metadata
Distribution interface shall provide the necessary information to
allow the Downstream CDN to acquire the content from an upstream
source (e.g. Acquisition protocol and Uniform Resource Identifier
in Upstream CDN- or rules to construct this URI).[HIGH] The CDNI metadata shall allow signaling of one or more upstream
sources, where each upstream source can be in the Upstream CDN, in
another CDN, the CSP origin server or any arbitrary source
designated by the Upstream CDN. Note that some upstream sources
(e.g. the content origin server) may or may not be willing to
serve the content to the Downstream CDN, if this policy is known
to the Upstream CDN then it may omit those sources when exchanging
CDNI metadata.[HIGH] The CDNI Metadata Distribution interface shall allow the Upstream
CDN to request addition and modification of CDNI Metadata into the
Downstream CDN.[HIGH] The CDNI Metadata Distribution interface shall allow removal of
obsolete CDNI Metadata from the Downstream CDN (this could, for
example, be achieved via an explicit removal request from the
Upstream CDN or via expiration of a Time-To-Live associated to the
Metadata).[HIGH] The CDNI Metadata Distribution interface shall allow association
of CDNI Metadata at the granularity of individual object. This is
necessary to achieve fine-grain Metadata distribution at the level
of an individual object when necessary.[HIGH] The CDNI Metadata Distribution interface shall allow association
of CDNI Metadata at the granularity of an object set. This is
necessary to achieve scalable distribution of metadata when a
large number of objects share the same distribution policy.[HIGH] The CDNI Metadata Distribution interface shall support multiple
levels of inheritance with precedence to more specific metadata.
For example, the CDNI Metadata Distribution protocol may support
metadata that is applicable to any content, metadata that is
applicable to a content collection and metadata that is applicable
to an individual content where content level metadata overrides
content collection metadata that overrides metadata for any
content.[HIGH] The CDNI Metadata Distribution interface shall ensure that
conflicting metadata with overlapping scope are prevented or
deterministically handled.[HIGH] The CDNI Metadata Distribution interface shall provide indication
by the Downstream CDN to the Upstream CDN of whether the CDNI
metadata (and corresponding future request redirections) is
accepted or rejected. When rejected, the CDNI Metadata
Distribution protocol Must allow the Downstream CDN to provide
information about the cause of the rejection.[HIGH] The CDNI Metadata Distribution interface shall allow signaling of
content distribution control policies. For example, this could
potentially include:geo-blocking information (i.e. Information defining
geographical areas where the content is to be made available
or blocked)availability windows (i.e. Information defining time
windows during which the content is to be made available or
blocked; expiration time may also be included to remove content)delegation whitelist/blacklist (i.e. Information defining
which Downstream CDNs the content may/may not be delivered
through)[HIGH] The CDNI Metadata interface shall be able to exchange a set of
well-accepted metadata elements with specified semantics (e.g. start of time window, end of time window).[HIGH] The CDNI Metadata interface shall allow exchange of opaque metadata element, whose semantic is
not defined in CDNI but established by private CDN agreement.[HIGH] The CDNI Metadata Distribution interface shall allow signaling of
authorization checks and validation that are to be performed by
the surrogate before delivery. For example, this could potentially
include:need to validate URI signed information (e.g. Expiry time,
Client IP address).[LOW] The CDNI Metadata Distribution interface may allow signaling of
CDNI-relevant surrogate cache behavior parameters. For example,
this could potentially include:control of whether the query string of HTTP URI is to be
ignored by surrogate cachecontent revalidation parameters (e.g. TTL)This section identifies the requirements related to the CDNI Logging
interface. We observe that while the CDNI Logging interface is currently
discussed as a single "protocol", further analysis will determine
whether the corresponding requirements are to be realized over a single
interface and protocol, or over multiple interfaces and protocols.[HIGH] The CDNI logging architecture and interface shall ensure reliable
logging of CDNI events.[HIGH] The CDNI Logging interface shall provide logging of deliveries and
incomplete deliveries to
User Agents performed by the Downstream CDN as a result of request
redirection by the Upstream CDN.[MED] In the case of cascaded CDNs, the CDNI Logging interface shall
allow the Downstream CDN to report to the Upstream CDN logging for
deliveries and incomplete deliveries performed by the Downstream CDN itself as well as
logging for deliveries and incomplete deliveries performed by cascaded CDNs on behalf of the
Downstream CDN.[HIGH] The CDNI Logging interface shall provide logging of distribution
performed by the Upstream CDN as a result of acquisition request
by the Downstream CDN.[HIGH] The CDNI Logging interface shall support batch/offline exchange
of logging records.[MED] The CDNI Logging interface should also support additional timing
constraints for some types of logging records (e.g. near-real time
for monitoring and analytics applications)[HIGH] The CDNI Logging interface shall define a log file format and a
set of fields to be exported through the Logging protocol, with
some granularity (e.g. On a per content type basis).[HIGH] The CDNI Logging interface shall define a transport mechanisms to
exchange CDNI Logging files.[MED] The CDNI Logging interface may allow a CDN to query another CDN
for relevant current logging records (e.g. For on-demand access to
real-time logging information).[LOW] The CDNI Logging interface may support aggregate/ summarized logs
(e.g. total bytes delivered for a content regardless of individual User Agents
to which it was delivered).[LOW] The CDNI Logging interface shall support logging of
performance data for deliveries to User Agents performed
by the Downstream CDN as a result of request redirection
by the Upstream CDN. Performance data may include various
traffic statistics (the specific parameters are to be
determined). The CDNI Logging interface shall support the
Upstream CDN to indicate the nature and contents of the
performance data to be reported by the Downstream CDN.[MED] The CDNI Logging interface shall support logging of
consumed resources (e.g. storage, bandwidth) to the Upstream CDN
for deliveries where content is stored by the Downstream CDN for delivery to
User Agents. The information logged may include the type
of storage (e.g., Origin, Intermediate, Edge, Cache) as
well as the amount of storage (e.g., total GB, GB used,
per time period, per content domain) all of which may
impact the cost of the services.[MED] In the case of cascaded CDNs, the CDNI Logging
interface shall support the Downstream CDN to report
consumed resources (e.g. storage, bandwidth) to the Upstream CDN
where content is stored by the Downstream CDN itself as well as logging for
storage resources when content storage is performed by
cascaded CDNs on behalf of the Downstream CDN.[HIGH] The CDNI Logging interface shall support logging of
deleted objects from the Downstream CDN to the Upstream
CDN as a result of explicit delete requests on via the CDNI
Control interface from the Upstream CDN.[HIGH] The CDNI Logging interface shall support
extensibility to allow proprietary information fields to
be carried. These information fields must be agreed upon
ahead of time between the corresponding CDNs.[HIGH] The CDNI Logging interface shall support the
exchange of extensible log file formats to support
proprietary information fields. These information fields
must be agreed upon ahead of time between the corresponding CDNs.This section identifies the requirements related to the CDNI
security. Some of those are expected to affect multiple or all
protocols.[HIGH] All the CDNI interface shall support secure operation over
unsecured IP connectivity (e.g. The Internet). This includes
authentication, confidentiality, integrity protection as well as
protection against spoofing and replay.[HIGH] The CDNI solution shall provide sufficient protection against
Denial of Service attacks. This includes protection against
spoofed delivery requests sent by user agents directly to a
Downstream CDN attempting to appear as if they had been redirected
by a given Upstream CDN when they have not.[MED] The CDNI solution should be able to ensure that for any given
request redirected to a Downstream CDN, the chain of CDN
Delegation (leading to that request being served by that CDN) can
be established with non-repudiation.[MED] The CDNI solution should be able to ensure that the Downstream
CDN cannot spoof a transaction log attempting to appear as if it
corresponds to a request redirected by a given Upstream CDN when
that request has not been redirected by this Upstream CDN. This
ensures non-repudiation by the Upstream CDN of transaction logs
generated by the Downstream CDN for deliveries performed by the
Downstream CDN on behalf of the Upstream CDN.[LOW] The CDNI solution may provide a mechanism allowing an Upstream
CDN that has credentials to acquire content from the CSP origin
server (or another CDN), to allow establishment of credentials
authorizing the Downstream CDN to acquire the content from the CSP
origin server (or the other CDN) (e.g. In case the content cannot
be acquired from the Upstream CDN).This document makes no request of IANA.Note to RFC Editor: this section may be removed on publication as an
RFC.This document discusses CDNI security requirements in .This document reflects the contributions from the following authors:Cisco Systemsflefauch@cisco.comCisco Systemsmvittal@cisco.comBTgrant.watson@bt.comThis document leverages the earlier work of the IETF CDI working
group in particular as documented in , and .The authors would like to thank Gilles Bertrand, Christophe Caillet,
Bruce Davie, Phil Eardly, Ben Niven-Jenkins, Agustin Schapira, Emile Stephan, Eric Burger,
Susan He, Kevin Ma, and Daryl Malas for their input. Serge Manning along with Robert Streijl,
Vishwa Prasad, Percy Tarapore, Mike Geller, and Ramki Krishnan contributed to this document by
addressing the requirements of the ATIS Cloud Services Forum.CDI AAA Requirements,
draft-gilletti-cdnp-aaa-reqs-01.txt