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

[Ben Niven-Jenkins <[e-mail]>]

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.

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.

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. 

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.

Ben