Re: [CDNi] CDNI Metadata Interface

[Francois Le Faucheur <[e-mail]>]

Hi again,

Thanks for the responses. See embedded below:

On 18 Oct 2011, at 07:26, Kevin J Ma wrote:

> Hi Francois,
> 
>  comments inline:
> 
>> From: Francois Le Faucheur [mailto:[e-mail]]
>> Sent: Monday, October 17, 2011 3:43 PM
>> To: Kevin J Ma
>> Cc: Francois Le Faucheur; [e-mail]
>> 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.

Do we agree POST would normally be dis-allowed in dCDN-uCDN direction (regardless of whether this is "enforced" by the Agent or something else)?

Regarding the use of POST for metadata creation, are you proposing it so it is used by the uCDN to "create" metadata in the dCDN (ie to pre-populate metadata in the dCDN) or are you proposing it so it is used by say a CP to "create" the metadata in the uCDN that will then be "pulled" by dCDN?
(for metadata pre-positioning in dCDN, I had been thinking more of an approach where the uCDN would issue a trigger instructing the dCDN to GET the corresponding metadata)

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

Agreed.

In any case, I would suggest that you discuss/document directionality in upcoming versions, possibly though some table capturing all the possible cases.

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

In my opinion, everything would typically operate as a chain, because the typical relationships between entities will be as a chain:
CP knows CDN-A, CDN-A knows CDN-B, CDN-B knows CDN-C.
So:
	* CDN-A would be responsible for crafting the metadata that will be pulled by CDN-B. CDN-A may elect to allow CP to directly populate (some/all) these metadata (so it does correctly reflect its policy).
	* CDN-B would then be responsible for crafting the metadata that will be pulled by CDN-C. CDN-B may elect to allow CDN-A to directly populate (some/all) these metadata (so it does correctly reflect its policy).
	* etc.

In any case, do you agree with the idea of having the hostname/resource-sets be tied to the Agent (so they can be different on a per CDN basis)?

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

I do think it is useful to associate to a domain something that is more flexible than hostname. For example, a hostname+beginning-of-path.
In some cases, it will just be hostnames. In some cases, it will be finer-grain

Thanks

Francois

> 
>> * 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cdni
>> 
> 



Francois Le Faucheur
Distinguished Engineer
Corporate Development
[e-mail]
Phone: [phone]
Mobile: [phone]



Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com


 


 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html