Re: [CDNi] Some questions regarding draft-ma-cdni-metadata

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

Hi Ben,

  responses inline:

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Ben Niven-Jenkins
> Sent: Monday, October 17, 2011 11:28 AM
> To: [e-mail]
> Subject: [CDNi] Some questions regarding draft-ma-cdni-metadata
> 
> Kevin,
> 
> I read draft-ma-cdni-metadata but I am struggling a little to understand
> how it fits into the overall framework of CDNI.
> 
> When I read the draft it appeared to me to be aimed more at a Content
> Provider or CDN Provider configuring the authoritative CDN rather that for
> Metadata exchange between CDNs because of its use of Agents, the fact it
> keeps all metadata opaque and because a lot of the protocol description is
> about how to create and modify metadata records which only seems to apply
> to the authoritative CDN.

I attempted to create an extensible representation for metadata and a
complete protocol for manipulating metadata, though, not all users of
the interface will need all aspects.  Do you feel that the protocol is
deficient for non-authoritative CDN use, or that authoritative CDNs do
not need the metadata interface?

> Agents:
> The draft states that "The Agent object contains basic information for
> authenticating entities which require access to Metadata." However it is
> not clear to me how the concept of the Agent object fits within the
> framework of CDNI as the details of the different Agents that may be able
> to access metadata for a Content Service will be specific the to CDN
> distributing that CDNI metadata. In other words I can't see why one would
> need to distribute Agent details between CDNs over CDNI because the Agents
> that are relevant for an uCDN are likely different to the Agents that a
> relevant to a dCDN.

It was not intended that agent information be distributed between
CDNs, that was what I tried to convery with the text stating: 
  "Domains and Agents MAY be created as a part of an
   off-line business negotiation process or as a part of the CDNI
   bootstrapping process."
Susan had a similar question about who would be responsible for the
creation of agents.  I will clarify that in the next version. 

> Later on the draft states:
>    The association of each Metadata to an Agent allows different Agents
>    to retrieve different Metadata values for a given URI in the given
>    Domain.  This is intended to allow CDNs to separate upstream Metadata
>    from downstream Metadata (e.g., a uCDN content acquisition URL may
>    point to a CP origin, however the content acquisition URL that the
>    dCDN retrieves from the uCDN may point at a surrogate in the uCDN).
> 
> This implies that the specification of Agents is really for imposing a
> specific implementation on CDNs in how they manage metadata received from
> a uCDN and how they expose that metadata to dCDNs. As the scope of CDNI
> does not cover the internal workings or operation of a particular CDN it
> would appear to me that imposing a particular internal mechanism for a
> single CDN to manage & distribute CDNI metadata is inappropriate for the
> CDNI WG.

The point was that different consumers of the metadata interface may
require different responses (or they may not).  Could that be left up
to individual implementations?  Perhaps.  I am not sure what internal
mechanism this imposes?  Are you saying that CDNI should only define
the metadata semantics, and not the storage representation?  My goal
was to define a generic representation, that could adapt to any 
semantics?  The agent is a part of that, though, in the degenerate
case of a single agent, nothing is lost?

> Metadata:
> I am a little confused about the desire to keep the actual specification
> of metadata opaque. In order for a CDN to do anything useful with the CDNI
> metadata it receives it needs to understand the syntax and semantics of
> the metadata it receives, however the draft intentionally keeps both the
> syntax and semantics for the metadata properties as well as any associated
> values opaque to any CDN that receives or distributes the associated
> metadata and says the associated "functionality SHOULD be agreed upon a
> priori by CDN operators, however, these negotiations are beyond the scope
> of CDNI."
> 
> Of course, the syntax and semantics of the CDNI metadata could be agreed
> out of band between the operators of the interconnected CDNs but doing
> that for all metadata properties that would be needed to meet the
> objectives of CDNI does not IMO provide any real advantage over what one
> could do today by configuring individual services in different CDNs and
> using CDNI request routing to redirect requests between those services in
> each CDN.
> 
> I can see that the meaning of the value for a specific metadata property
> might need to be opaque because the value may be applied differently by
> different CDNs (e.g. a more general "QoS" value that each CDN maps to an
> appropriate DSCP value depending on how the underlying network has been
> configured/deployed) but those are more likely to be exceptions rather
> than the general rule and in any case the property itself would still need
> to be specified & defined, so even with that in mind I'm struggling to see
> the value in keeping all metadata opaque.

My concern with defining all the semantics of metadata and designing a
protocol around that, is you typically end up with a less extensible
design.  I would not want to have to update the metadata interface rfc
just to support a new piece of metadata in the future.  I am not saying
that we should not define metadata, I just think it should be separate
from the data model and the protocol, so I concentrated on those first.
I definitely feel that we should define a base set of metadata that all
CDNs should support.  I do not think the draft prevents that.

thanx.

--  Kevin J. Ma

> Ben
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni