Re: [CDNi] CDNI Metadata Interface

[Kevin J Ma <[e-mail]>]

Hi Susan,

  inline:

> -----Original Message-----
> From: HeXiaoyan [mailto:[e-mail]]
> Sent: Tuesday, October 18, 2011 5:27 AM
> To: Kevin J Ma; [e-mail]
> Subject: RE: [CDNi] CDNI Metadata Interface
> 
> Kevin,
> > Adding the one-to-many relationship
> > between the hostname and metadata tables would cause duplicate entries
> > in the metadata table (one per hostname)?
> Sorry, after reading the draft again, I have to say my intention was that
> the relationship between the Hostname and Metadata object should be a
> one-to-zero or one-to-one relation like the figure below. All metadata
> associated with one hostname or one url prefix which at least containing a
> hostname should be grouped in one Metadata object (i.e. explicitly define
> all the properties of each hostname in one Metadata object). I think this
> is
> more straight-forward and consistent with the existing today CDN metadata
> model.  Is it possible for you to consider modifying your proposal on
> this?

Francois had a similar comment.  One resolution would be to move the hostname
into the metadata object and use it as part of the URI lookup?  Would that
make more sense?

>    +----------+
>   |        | 1
>   | Agent   +---------------------------+
>   |        |                |
>   +----+-----+                  |
>        | 1..*                |
>        |                    |
>        | 1                   | 1
>    +----+-----+             +----+-----+
>   |         |          |          |
>   | Domain  |          |  Metadata |
>   |         |          |          |
>    +----+-----+             +-----+----+
>        | 1                   |
>        |                     |
>        | 1..*                 |
>    +----+-----+                 |
>   |         |    1   0..1     |
>   | Hostname +----------------------------+
>   |         |
>    +----------+
> 
> When reading through the examples in section 3.3.3, I found no agent
> id/name
> is conveyed in the metadata retrieval message, I remember we discussed
> that
> for different agent the upCDN may response with different value of a
> metadata, would you double check that?
> Thanks.

In the examples, I used HTTP basic auth, so the agent name/password is
encoded in the Authorization header.

thanx.

--  Kevin J. Ma

> Best Regards
> Xiaoyan(Susan) He
> 
> -----Original Message-----
> From: Kevin J Ma [mailto:[e-mail]]
> Sent: Tuesday, October 18, 2011 2:26 AM
> To: HeXiaoyan; [e-mail]
> Subject: RE: [CDNi] CDNI Metadata Interface
> 
> 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:[e-mail]]
> > Sent: Monday, October 17, 2011 3:14 AM
> > To: Kevin J Ma; [e-mail]
> > 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:[e-mail]]
> > Sent: Friday, October 14, 2011 10:26 PM
> > To: HeXiaoyan; [e-mail]
> > Subject: RE: [CDNi] CDNI Metadata Interface
> >
> > Hi Susan,
> >
> >   responses inline:
> >
> > > -----Original Message-----
> > > From: HeXiaoyan [mailto:[e-mail]]
> > > Sent: Friday, October 14, 2011 5:35 AM
> > > To: Kevin J Ma; [e-mail]
> > > 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:[e-mail]]
> > > Sent: Tuesday, October 11, 2011 11:30 PM
> > > To: HeXiaoyan; [e-mail]
> > > Subject: RE: [CDNi] CDNI Metadata Interface
> > >
> > > Hi Susan,
> > >
> > >   thanx for the comments, responses inline:
> > >
> > > > -----Original Message-----
> > > > From: HeXiaoyan [mailto:[e-mail]]
> > > > Sent: Tuesday, October 11, 2011 5:28 AM
> > > > To: Kevin J Ma; [e-mail]
> > > > 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: [e-mail] [mailto:[e-mail]] On Behalf
> > Of
> > > > Kevin J Ma
> > > > Sent: Friday, October 07, 2011 1:21 PM
> > > > To: [e-mail]
> > > > 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
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/cdni
>