Re: [CDNi] CDNI Metadata Interface

Hi Francois,

  comments inline:

> From: Francois Le Faucheur [mailto:flefauch@cisco.com]
> Sent: Monday, October 17, 2011 3:43 PM
> To: Kevin J Ma
> Cc: Francois Le Faucheur; cdni@ietf.org
> Subject: Re: [CDNi] CDNI Metadata Interface
> 
> Hello Kevin,
> 
> [with Individual hat on]
> 
> A first set of high level questions:
> 
> * directionality of metadata creation/retrieval/removal/update mechanism:
> Could you clarify which of the above operation you see possibly happening
> in which direction?
> For example, regarding update/removal, do you see:
> 	*a)  the POST possibly being issued towards the uCDN to
> update/remove some metadata in the uCDN repository?
> 	*b) the POST possibly being issued by the uCDN towards the dCDN to
> update/remove some metadata in the dCDN repository (after some out-of-date
> metadata had been retrieved by dCDN from uCDN).
> For example, regarding retrieval, clearly we want the dCDN to issue a GET
> towards the uCDN to acquire metadata. Now do you see that the GET could
> possibly be also issued by the uCDN to check metadata stored by the dCDN?

I think POSTs make the most sense going from upstream to downstream.
The agent was intended to moderate this, since any given pair of CDNs
could be both a uCDN and a dCDN for each other in different domains.

I see no reason why GETs could not go in both directions.  I can see a
case where upstream entities would want to verify downstream entities.

> * in your CDNI metadata model, a "domain" is directly associated with a
> set of "hostnames". So this assumes that the same set of unmodified
> hostnames is used unmodified everywhere in all the potential dCDNs. That
> can be the case in some deployment, but that may not always be the case.
> For example, when HTTP redirection is used across CDNs, an upstream CDN
> may want to modify (possibly hide) the actual content provider hostnames
> (and possibly part of the URI path) when redirecting to a dCDN (I believe
> this is mentioned in the framework).

I was thinking (though it is not noted in the document) that hostname
lists could be different in different dCDNs.  What is not entirely
clear to me is how metadata would get set across cascaded CDNs,
i.e., if the CP contracts CDN-A, and CDN-A makes a deal with CDN-B,
and CDN-B makes a deal with CDN-C, does the CP or CDN-A know about
CDN-C and is the CP or CDN-A responsible configuring metadata on
CDN-C?  Or, is CDN metadata only configured by the most immediate
uCDN (or the CP), i.e., only CDN-B (or the CP) will know the values of
metadata in CDN-C?

> Would you consider modifying your proposed CDNI model to allow for the
> fact that a domain may be "referenced" differently by some dCDNs than by
> the uCDN?
> I think it means:
> 	* the concept of "hostnames" should be made more flexible so it
> matches not just on hostnames but on pattern match over hostname/path.
> Let's call this "resource sets".
> 	* "resource sets" should be dependent on "Agents". So perhaps it
> shoudl be folded inside your "Metadata" so it can be defined on a per
> "dCDN" basis.
> Would that work for you?

Would the goal be to use the entire hostname/uri as a single combined
key?  I do not have a problem with merging them if we think that it
would be useful.

> * in section 3.3.3, you have a couple of examples showing
> "/CDNI/MI/domain". Should those not say "/CDNI/MI/metadata"?

Yep.  Those are cut and paste errors, good catch!  I will fix those.

thanx!

--  Kevin J. Ma

> Cheers
> 
> Francois
> 
> 
> 
> 
> On 6 Oct 2011, at 22:21, Kevin J Ma wrote:
> 
> 
> Hi all,
> 
>  Just uploaded a new I-D with a proposed metadata model and API:
> 
>    http://www.ietf.org/internet-drafts/draft-ma-cdni-metadata-00.txt
> 
>  The model takes a rather generic approach to metadata representation
>  to support opaque metadata and addresses some of the security issues
>  associated with metadata retrieval.  Comments welcome.
> 
> thanx.
> 
> --  Kevin J. Ma
> 
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni
> 