Re: [CDNi] CDNI Metadata Interface

Hi Francois,

>     * 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.

Are you proposing remove the "hostname" object or keep it and adding
"resource sets" to "Metadata"?

I think the "hostname" object should be kept as sometimes the customer would
possibly deploy a enforcement policy associated to a hostname , e.g. for
hostname associated with  a set of web pages, CP may prefer DNS routing as
HTTP redirection will cause cookie issues among others. Keeping hostname
level can provide cp with this flexibility.  

Best Regards

Xiaoyan(Susan) He

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of
Francois Le Faucheur
Sent: Tuesday, October 18, 2011 3:43 AM
To: Kevin J Ma
Cc: 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?

* 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). 

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?

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

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