Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-metadata-02.txt

From: Scott Wainner <[email-masked]>
Date: Fri, 02 Aug 2013 17:35:27 -0400

Comments on the metadata-02 draft ...

Scott Wainner

*
4.2.6.  Auth**
**
**   An Auth object defines authentication and authorization methods to be**
**   used during content delivery and content acquisition, e.g. methods**
**   such as tokenization and URL Signing.**
**
**   [Ed.  Need to synchronize authentication configuration with CDNI URL**
**   signing draft definitions.]**
*
sw> There is no need for a uCDN to direct the User Agent to a dCDN if 
that dCDN doesn't support the authentication method invoked.  URL 
signing draft defines at least two methods:

1) URL Signing
2) Tokenization

and the attributes associated with the method defined.

I consider two models:

a. dCDN advertises its AUTH methods in capabilities (FCI); the uCDN 
finds at least one of these methods acceptable or not
b. uCDN announces the method(s) it requires (MI) ; the dCDN either 
accepts a method or rejects them all

In the case of DNS redirect, the method is defined by the CSP and may be 
inherently understood by the uCDN.  That method needs to be conveyed to 
the dCDN and where the dCDN is validated by the uCDN; otherwise, the 
dCDN won't be able to authenticate the URL created by the CSP.  This 
seems like a good candidate for the MI as a mandatory attribute.  For a 
given Host in the HostIndex, the authentication method and attributes 
can be defined:

     REFERENCE leung-cdni-url-signing-2.txt

     Method: Signature or SignedToken
     Enforcement Attributes: ET and CIP
     Signature Attributes: MD or DS
     Computation Attributes: VER, KID, HF

*4.2.8.  Grouping**
**
**   A Grouping object identifies a large group of content to which this**
**   content belongs.**
**
**      Property: ccid**
**
**         Description: Content Collection identifier for an application-**
**         specific purpose such as logging.**
**
**         Type: String**
**
**         Mandatory-to-Specify: No.  Default is an empty string.**
**
**      Property: sid**
**
**         Description: Session identifier for an application-specific**
**         purpose such as logging.**
**
**         Type: String**
**
**         Mandatory-to-Specify: No.  Default is an empty string.**
*
sw>  According to the cdni-logging-05.txt, the dCDN creates and assigns 
a Session-ID.  It seems to me that the CSP may create a Session-ID.  
Likewise, a uCDN would also create a Session-ID for any delegation to a 
dCDN.  Ideally, the CSP Session-ID, the uCDN Session-ID, and the dCDN 
Session-ID would be correlated such that the operators can track the 
hand-off of the referrals: CSP -> uCDN -> dCDN -> dCDN -> deliveryNode.

Perhaps the Session-ID has some defined hierarchy that explicitly traces 
the referrals:

     Session-ID:= [dcdn-id.ucdn-id.csp-id.]

If that is the case, the MI could convey the uCDN's part of the Session-ID:

     sid = ucdn-id.csp-id

where the dCDN can prepend its assigned Session-ID.

In a similar manner, a dCDN that delegates to another dCDN would prepend 
its assigned Session-ID:

     sid = dcdn-1-id.ucdn-id.csp-id

Now we need to define the format of the Session-ID.  Refer to I-D. 
brandenburg-cdni-has which describes the session-ID, but it remains 
undefine.

*6.2.  Retrieval of CDNI Metadata resources**
**
**   ....**
**
**   Where a downstream CDN is interconnected with multiple upstream CDNs,**
**   the downstream CDN must decide which upstream CDN's CDNI metadata**
**   should be used to handle a particular User Agent request.**
*
sw> I would think the dCDN MUST request the metadata from the uCDN that 
provided the User Agent the request.

*   When application level redirection (e.g. HTTP 302 redirects) is being**
**   used between CDNs, it is expected that the downstream CDN will be**
**   able to determine the upstream CDN that redirected a particular**
**   request from information contained in the received request (e.g. via**
**   the URI).  With knowledge of which upstream CDN routed the request,**
**   the downstream CDN can choose the correct metadata server from which**
**   to obtain the HostIndex.  Note that the HostIndex served by each uCDN**
**   may be unique.**
*
sw> Now that we may incorporate the Request Interface in the WG, the URI 
prepared by the uCDN for the dCDN and passed via the User Agent client 
(Interative Mode) may contain a reference such that the dCDN will know 
the originator of the User Agent's request.

*   In the case of DNS redirection there is not always sufficient**
**   information carried in the DNS request from User Agents to determine**
**   the upstream CDN that redirected a particular request (e.g. when**
**   content from a given host is redirected to a given downstream CDN by**
**   more than one upstream CDN) and therefore downstream CDNs may have to**
**   apply local policy when deciding which upstream CDN's metadata to**
**   apply.**
*
sw> I would think that the dCDN would have a unique CNAME for each uCDN 
that it services, thus the dCDN can associate the incoming request to a 
particular uCDN by association of the CNAME to the uCDN.

     Example:
         uCDN-1 CNAME for dCDN-X: ucdn-1.dcdn-x.com
         uCDN-2 CNAME for dCDN-X: ucdn-2.dcdn-x.com
     Now dCDN-X knows the originator of the DNS referral; hence, the 
dCDN can make metadata calls to the appropriate uCDN.

On 7/15/13 5:12 PM, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF.
>
> 	Title           : CDN Interconnect Metadata
> 	Author(s)       : Ben Niven-Jenkins
>                            Rob Murray
>                            Grant Watson
>                            Matt Caulfield
>                            Kent Leung
>                            Kevin J. Ma
> 	Filename        : draft-ietf-cdni-metadata-02.txt
> 	Pages           : 43
> 	Date            : 2013-07-15
>
> Abstract:
>     The CDNI Metadata Interface enables interconnected CDNs to exchange
>     content distribution metadata in order to enable content acquisition
>     and delivery.  The CDNI metadata associated with a piece of content
>     provides a downstream CDN with sufficient information for the
>     downstream CDN to service content requests on behalf of an upstream
>     CDN.  This document describes both the core set of CDNI metadata and
>     the protocol for exchanging that metadata.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-cdni-metadata-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-metadata-02
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
> .
>