Subject: Re: [CDNi] review comments to draft-ietf-cdni-metadata-08

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 10 Nov 2014 03:29:21 +0000

Linda,

I thought it would be worthwhile to post a summary of our hallway conversation just now on your question below for the benefit of the wider WG and to close this review comment.

You are essentially asking whether it would be possible to represent the data structures used by the CDNI Metadata draft in other formats, such as XML.

As we discussed just now, it is perfectly possible to represent the CDNI metadata data structures in other formats, but after some debate within the WG consensus was to specify the interfaces using JSON, which is what is specified in the Metadata document you kindly reviewed for us.

Regards
Ben

On 30 Oct 2014, at 15:53, Linda Dunbar <[email-masked]> wrote:

> Ben, 
> 
> Your draft showed JSON model. The same information can be represented by other models, like XML or YANG. 
> 
> Therefore, I think it is better to have a section describing the information model, and have another section showing JSON data model. 
> 
> Linda 
> -----Original Message-----
> From: Ben Niven-Jenkins [mailto:[email-masked]] 
> Sent: Tuesday, October 28, 2014 6:10 PM
> To: Linda Dunbar
> Cc: [email-masked]; [email-masked]
> Subject: Re: [CDNi] review comments to draft-ietf-cdni-metadata-08
> 
> Linda,
> 
> On 28 Oct 2014, at 22:22, Linda Dunbar <[email-masked]> wrote:
> 
>> Ben, Rob, Matt, and Kevin,
>> 
>> Is section 3 meant for "Information Model"?
>> 
>> I think there should be a section to describe the information model (or UML) for the CDNi Meta data before the actual data model.
> 
> Could you expand a bit on what improvement you think including an information model would add to the document?
> 
> I don't recall coming across something like that in other protocols specifications.
> 
> Thanks
> Ben
> 
>> 
>> Linda
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 17 Nov 2014 11:17:47 +0000

Linda,

My responses are inline below...

On 30 Oct 2014, at 21:05, Linda Dunbar <[email-masked]> wrote:

> Ben,
>  
> Thanks for the reply.
>  
> More suggestions inserted below:
>  
> Sent: Tuesday, October 28, 2014 6:29 PM
> To: Linda Dunbar
> On 28 Oct 2014, at 20:46, Linda Dunbar <[email-masked]> wrote:
>  
> > This draft is long and defined a lot of terms: Host Index, Host Match, host-meta-data, Path Match, path-meta-data, generic-metadata-objects, etc.
> > Is the intent of the draft to define the proper data structure for dCDN to request content from upstream CDN?
>  
> No. The intent is to define data structures for describing how to deliver content, as well as policies for where is allowed to receive it, etc.
>  
> [Linda] It would make the document easier to read if you add this statement to the Introduction Section.

The introduction already says:
   The CDNI metadata associated with a piece of content (or with a set
   of content) provides a downstream CDN with sufficient information for
   servicing content requests on behalf of an upstream CDN in accordance
   with the policies defined by the upstream CDN.

and then says later on:
   Specifically, this document specifies:

   o  A data structure for mapping content requests and redirection
      requests to CDNI Metadata objects (Section 3 and Section 4.1).

   o  An initial set of CDNI Generic Metadata objects (Section 4.2).

   o  A RESTful web service for the transfer of CDNI Metadata
      (Section 6).

which I think covers what I say above. Can you suggest specific text changes you think would address your concern?
 
> The current Abstract section says that the draft also describes the “Protocol for exchange Metadata”. I would suggest Section 5 (Leverage existing protocol) to simply “Protocols for exchanging Metadata”.  In the content, you can say why you need to leverage the existing protocols.

Section 5 doesn't talk about leveraging existing protocols. Section 2 mentions it as part of giving the high level design principles the authors tried to follow.

Section 2 already says
   Leveraging existing protocols avoids reinventing common mechanisms
   such as data structure encoding (e.g., JSON) and data transport
   (e.g., HTTP).

but that is really just background information. Section 6 specifies the metadata exchange protocol (the metadata interface itself) in detail.

> The details of how to obtain the content is only one part of describing how to deliver the content.
>  
> > Is the following correct?
> > 
> > host-meta-data == “IP addresses”?
>  
> host-meta-data isn't used in the document. I'm assuming you are asking what the value of the host-metadata property is?
>  
> It is a link to a URI that returns a HostMetadata object which is a JSON object describing the default CDNI Metadata objects for content served from that host.
>  
> [Linda] Is there any significance to emphasize on the “Link to a URI” instead simple the “URI”?
> Do you mean the value of “HostMetadata” is a link to a URI?

The value of the host-metadata property is a HostMetadata object or a Link object pointing to a HostMetadata object. The Link object contains the URI and the media type of the HostMetadata object. The Link object (what I refer to as "a link" in my previous e-mail) is described in Section 4.3.1.

Regards
Ben

> Thanks, Linda