Re: [CDNi] CDNI Metadata Interface
Kevin J Ma <kevin.ma@azukisystems.com> Mon, 17 October 2011 18:26 UTC
Return-Path: <kevin.ma@azukisystems.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 2644021F85A4 for <cdni@ietfa.amsl.com>; Mon, 17 Oct 2011 11:26:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599]
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 JdhWn7AwNe0V for <cdni@ietfa.amsl.com>; Mon, 17 Oct 2011 11:26:20 -0700 (PDT)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 136F121F8593 for <cdni@ietf.org>; Mon, 17 Oct 2011 11:26:19 -0700 (PDT)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6B72A79F8B4; Mon, 17 Oct 2011 14:26:19 -0400 (EDT)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E00C979F878; Mon, 17 Oct 2011 14:26:16 -0400 (EDT)
Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Mon, 17 Oct 2011 14:26:16 -0400
From: Kevin J Ma <kevin.ma@azukisystems.com>
To: HeXiaoyan <hexiaoyan@huawei.com>, "cdni@ietf.org" <cdni@ietf.org>
Date: Mon, 17 Oct 2011 14:26:14 -0400
Thread-Topic: [CDNi] CDNI Metadata Interface
Thread-Index: AcyErDmDceDqNX+AQtKwjumpTmgL9wDNgegQABC/ZGAAiOeZgAAMTEwgAIdhgUAAENsBMA==
Message-ID: <291CC3F9E50E7641901A54E85D0977C651B668260B@MAILR002.mail.lan>
References: <291CC3F9E50E7641901A54E85D0977C651B50AF9D2@MAILR002.mail.lan> <010d01cc87f8$10bc5940$32350bc0$@com> <291CC3F9E50E7641901A54E85D0977C651B51517AD@MAILR002.mail.lan> <000501cc8a54$921298c0$b637ca40$@com> <291CC3F9E50E7641901A54E85D0977C651B523F27E@MAILR002.mail.lan> <000201cc8c9c$5d426180$17c72480$@com>
In-Reply-To: <000201cc8c9c$5d426180$17c72480$@com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Mon, 17 Oct 2011 18:26:21 -0000
Hi Susan, ok, I think I understand now. In writing the draft, I was not sure if this would be a typical use case. Adding the one-to-many relationship between the hostname and metadata tables would cause duplicate entries in the metadata table (one per hostname)? One alternative would be to use a many-to-many relationship instead, though verification of domain constraints on creation becomes more complex. In general, if we think that this flexibility is required, I have no issue with making changes to the model, however, if it is unlikely to be used, I would favor the simpler approach. Is a one-to-many relationship between the hostname and metadata tables that much better than removing the hostname table completely (and just adding a hostname field to the domain, i.e., the degenerate case where each domain only has one hostname)? That is essentially what it would be doing? thanx. -- Kevin J. Ma > -----Original Message----- > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > Sent: Monday, October 17, 2011 3:14 AM > To: Kevin J Ma; cdni@ietf.org > Subject: RE: [CDNi] CDNI Metadata Interface > > Hi Kevin, > I share the view that the concept of Domain is useful, my suggestion is > linking metadata to Hostname and keep the Domain, > i.e. something like the figure below. Benefit is metadata associated with > one custormer can be grouped even different > Hostnames belong the Domain has different metadata value. > > > +----------+ > | | 1 > | Agent +---------------------------+ > | | | > +----+-----+ | > | 1..* | > | | > | 1 | 1 > +----+-----+ +----+-----+ > | | | | > | Domain | | Metadata | > | | | | > +----+-----+ +-----+----+ > | 1 | > | | > | 1..* | > +----+-----+ | > | | 1 0..* | > | Hostname +----------------------------+ > | | > +----------+ > > Thanks. > > Best Regards > Xiaoyan(Susan) He > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Friday, October 14, 2011 10:26 PM > To: HeXiaoyan; cdni@ietf.org > Subject: RE: [CDNi] CDNI Metadata Interface > > Hi Susan, > > responses inline: > > > -----Original Message----- > > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > > Sent: Friday, October 14, 2011 5:35 AM > > To: Kevin J Ma; cdni@ietf.org > > Subject: RE: [CDNi] CDNI Metadata Interface > > > > Hi Kevin, > > Thanks for the response. Some further concern, > > - I don't quite understand the restriction that require metadata of all > > hostnames in one Domain have same value. The case exist that for a > > specific > > metadata different hostnames often have different value. Compare with > > creating multiple Domains with less hostname sharing the same metadata, > I > > think link metadata to hostname not Domain is more simpler. > > From a conceptual perspective, it could be argued that the domain > object is extraneous. As an implementation detail, however, the > multi-table joins, imo, were simplified by having a central object > to define the domain, so I added one. From an operator perspective, > having a way to group multiple hostnames also seems useful, even > though, in the degenerate case, you could just have one hostname per > domain. If there is a concensus view that the domain is unnecessary, > it could be removed. > > > -I interpret the role of the Agent object is to identify entities > > communicated (correct me if I'm wrong), other interfaces in CDNI e.g. > > Logging interface needs such an parameter as well, a universal solution > > for > > that would be good, do you think the Agent object introduced in your > draft > > could also be applicable for other interfaces? > > I agree that the other interfaces (control/logging) will require some > type of authentication and security. The agent concept could certainly > be extended to other interfaces, and I agree that it would be good to > have the same solution for all interfaces > > thanx. > > -- Kevin J. Ma > > > Best Regards > > Xiaoyan(Susan) He > > > > -----Original Message----- > > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > > Sent: Tuesday, October 11, 2011 11:30 PM > > To: HeXiaoyan; cdni@ietf.org > > Subject: RE: [CDNi] CDNI Metadata Interface > > > > Hi Susan, > > > > thanx for the comments, responses inline: > > > > > -----Original Message----- > > > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > > > Sent: Tuesday, October 11, 2011 5:28 AM > > > To: Kevin J Ma; cdni@ietf.org > > > Subject: RE: [CDNi] CDNI Metadata Interface > > > > > > Hi Kevin, > > > Some quick questions and comments on this draft, > > > >The Metadata objects are each associated with a URI within the Domain > > and > > > accessible through any of the Hostnames... > > > - Could you further explain or give an example how a metadata is > > accessed > > > by > > > a Hostname within the Domain? And a further question is how the data > > model > > > works if a metadata is only associated with a specific Hostname within > > one > > > Doman? > > > > I was assuming that metadata would be valid for all hostnames. If a > > hostname > > needed separate metadata, a new domain would be required. I was > thinking > > of > > hostname as a first level restriction. My implementation does something > > along > > the lines of the following (where hostname is checked before metadata > > lookup): > > > > domain = get_param_from_query_string(getenv("QUERY_STRING"), "domain") > > if (!db_verify_hostname_for_domain(getenv("SERVER_NAME"), domain)) > > return error > > metadata = db_get_metadata_by_uri_domain_agent(getenv("REQUEST_URI"), > > domain, > > getenv("REMOTE_USER")) > > xml = generate_xml_for_metadata(metadata) > > return xml > > > > > - The relationship between Agent objects and Metadata objects is a > > > one-to-one relationship, does this mean one agent can only access one > > > Metadata within one Domain? > > > > That is a typo in the doc, good catch, thanx! It should be one to many. > > Each metadata must be associated with a single agent, but an agent can > be > > associated with multiple metadata. Agent-1 could have metadatas A, B, > and > > C, while agent-2 could have a separate value for metadatas A and B, and > > also > > have its own metadata D (that agent-1 does not have access to) > > > > > > The association of each Metadata to an Agent allows different Agents > > to > > > retrieve different Metadata values for a given URI in the given > Domain. > > > - Don't understand why each Metadata object needs to be bind with an > > Agent > > > explicitly, IMO, whether to return different value to different Agents > > is > > > an > > > inside process of the upCDN, what downCDN needs to do is just transmit > > its > > > identifier to the upCDN when retrieve a Metadata. > > > > I think the fact that a uCDN would want/need to give out different > values > > to > > different dCDNs requires that there be a way to represent and store that > > information. Having it explicitly in the model, i think, simplifies the > > implementation and guarantees that all implementation give this issue > > proper > > consideration. > > > > > - Which entity is responsible for creating the Agent objects within > one > > > Domain? Does the CP can 'see' the downCDNs and creates corresponding > > Agent > > > objects and other CDNs on the way just transmitted it or each upCDN > > > located > > > in the cascaded path creates a Agent object for each its downCDN? > > > > This is a good question. Different agents would need to be create by > > different > > entities, as you mention. I would expect each CDN to create agents to > > represent > > those (outside that CDN) who need access to the metadata interface. > > > > thanx! > > > > -- Kevin J. Ma > > > > > Thanks. > > > Best Regards > > > Xiaoyan(Susan) He > > > > > > -----Original Message----- > > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of > > > Kevin J Ma > > > Sent: Friday, October 07, 2011 1:21 PM > > > To: cdni@ietf.org > > > Subject: [CDNi] CDNI Metadata Interface > > > > > > 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
- [CDNi] CDNI Metadata Interface Kevin J Ma
- Re: [CDNi] CDNI Metadata Interface HeXiaoyan
- Re: [CDNi] CDNI Metadata Interface Kevin J Ma
- Re: [CDNi] CDNI Metadata Interface Francois Le Faucheur
- Re: [CDNi] CDNI Metadata Interface HeXiaoyan
- Re: [CDNi] CDNI Metadata Interface HeXiaoyan
- Re: [CDNi] CDNI Metadata Interface Kevin J Ma
- Re: [CDNi] CDNI Metadata Interface HeXiaoyan
- Re: [CDNi] CDNI Metadata Interface Kevin J Ma
- Re: [CDNi] CDNI Metadata Interface HeXiaoyan
- Re: [CDNi] CDNI Metadata Interface Francois Le Faucheur
- Re: [CDNi] CDNI Metadata Interface Kevin J Ma
- Re: [CDNi] CDNI Metadata Interface Kevin J Ma
- Re: [CDNi] CDNI Metadata Interface Francois Le Faucheur
- Re: [CDNi] CDNI Metadata Interface Kevin J Ma