Re: [CDNi] CDNI Metadata Interface

Francois Le Faucheur <flefauch@cisco.com> Tue, 18 October 2011 01:08 UTC

Return-Path: <flefauch@cisco.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07B521F8B5E for <cdni@ietfa.amsl.com>; Mon, 17 Oct 2011 18:08:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.554
X-Spam-Level:
X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKV82i8sZM8i for <cdni@ietfa.amsl.com>; Mon, 17 Oct 2011 18:08:04 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDE821F8B5C for <cdni@ietf.org>; Mon, 17 Oct 2011 18:08:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=7018; q=dns/txt; s=iport; t=1318900084; x=1320109684; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=US9SBrUo5p3aGR620d+U64+Jie8+gMX3S6IyIsYZfTg=; b=H91HEHlvS4PUdNz9P5lqRit6QI9XdHJ5tlgZ93jGrake6ehYuMKeeR5K ObqKNQTgp5XJ/rjGZmKEDN7sjkHX+T/p4BQDC56gu8E0YZc7IQLPkNngh UolnMN3Kjcwjvbng7IDm1NwSruqmPkPRmZDczxjZNeEAGfGDnvoGR+wez A=;
X-IronPort-AV: E=Sophos;i="4.69,362,1315180800"; d="scan'208,217";a="8452319"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 18 Oct 2011 01:08:04 +0000
Received: from sjc-vpn3-1006.cisco.com (sjc-vpn3-1006.cisco.com [10.21.67.238]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9I183J8025034; Tue, 18 Oct 2011 01:08:03 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-658--876546383"
From: Francois Le Faucheur <flefauch@cisco.com>
In-Reply-To: <291CC3F9E50E7641901A54E85D0977C651B50AF9D2@MAILR002.mail.lan>
Date: Mon, 17 Oct 2011 12:42:33 -0700
Message-Id: <EBE563EB-FE0D-49C1-8107-4BB2557D2B1A@cisco.com>
References: <291CC3F9E50E7641901A54E85D0977C651B50AF9D2@MAILR002.mail.lan>
To: Kevin J Ma <kevin.ma@azukisystems.com>
X-Mailer: Apple Mail (2.1084)
Cc: "cdni@ietf.org" <cdni@ietf.org>
Subject: Re: [CDNi] CDNI Metadata Interface
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cdni>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Oct 2011 01:08:05 -0000

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