Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 1]

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 22 Apr 2014 15:40:06 +0100

Francois,

Following up on this. I have made all the editorial changes you suggest below to the authors working copy of -07 so you should see them once we publish a new version.

Ben

On 18 Feb 2014, at 16:39, Francois Le Faucheur (flefauch) <[email-masked]> wrote:

> Folks,
> 
> I’ve started a WG Chair review of draft-ietf-cdni-metadata-06. Below is a first batch of comments.
> 
> Francois
> 
> 
> 
> ***Title:
> s/CDN Interconnect Metadata/CDN Interconnection Metadata/
> 
> 
> *** Authors:
> You currently list 6 authors, which I think exceeds the maximum expected number. You may need to consider splitting “editors” and “Contributing Authors”
> 
> 
> *** throughout the document:
> s/Metadata Interface/Metadata interface/
> 
> 
> *** section1:
> OLD:
> "
> CDNI enables a downstream CDN to service content requests on behalf
>    of an upstream CDN.  The CDNI metadata associated with a piece of
>    content (or with a set of contents) 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.
> 
>    The CDNI Metadata Interface is introduced by [RFC6707] along with
>    three other interfaces that may be used to compose a CDNI solution
>   (Control, Request Routing and Logging).  [I-D.ietf-cdni-framework]
>    expands on the information provided in [RFC6707] and describes each
>    interface, and the relationships between them, in more detail.  The
>    requirements for the CDNI metadata interface are specified in
>    [I-D.ietf-cdni-requirements].
> “
> NEW:
> “
> Content Delivery Networks Interconnection (CDNI) ([RFC6707]) enables a downstream CDN to service content requests on behalf of an upstream CDN.  
> 
>    The CDNI Metadata interface is discussed in [I-D.ietf-cdni-framework] along with
>    four other interfaces that may be used to compose a CDNI solution
>   (CDNI Control interface, CDNI Request Routing Redirection interface, CDNI Footprint & Capabilities Advertisement interface interface and Logging interface ).  [I-D.ietf-cdni-framework]
>    describes each interface, and the relationships between them.  The
>    requirements for the CDNI metadata interface are specified in
>    [I-D.ietf-cdni-requirements].
> The CDNI metadata associated with a piece of
>    content (or with a set of contents) 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.
> "
> 
> 
> *** section 1:
> OLD:
> “
> o  A data structure for mapping content requests to CDNI Metadata
>       properties (Section 3).
> “
> NEW:
> “
> o  A data structure for mapping content requests and redirection requests to CDNI Metadata
>       properties (Section 3).
> “
> 
> 
> *** section 1:
> s/Redirection Requests/redirection requests/
> s/Content Requests/content requests/
> 
> 
> *** section 1:
> “
> Specifically, this document proposes:
>    o  A data structure for mapping content requests to CDNI Metadata
>       properties (Section 3).
>    o  An initial set of CDNI Metadata properties (Section 4.2).
>    o  A RESTful web service for the transfer of CDNI Metadata
>       (Section 6).
> “
> Is there a reason why the metadtaa structure defined in sectio 4.1 is not mentioned here? 
> To me it seems an important part of the metadata specification.
> 
> 
> *** section 2:
> s/The proposed CDNI Metadata Interface/The CDNI Metadata Interface/
> 
> *** section 2:
> s/Deterministic mapping from redirection and content requests/Deterministic mapping from redirection requests and content requests/
> 
> 
> *** section 2:
> s/5. Leverage/5. Leveraging of/
> 
> 
> OLD:
> “
> Cacheability improves the latency of acquiring metadata while
>    maintaining its freshness and therefore improves the latency of
>    serving content requests.  The CDNI Metadata Interface uses HTTP to
>    achieve cacheability.
> “
> NEW:
> “
> Cacheability improves the latency of acquiring metadata while
>    maintaining its freshness, and therefore improves the latency of
>    serving content requests and redirection requests, without sacrifing accuracy.  The CDNI Metadata Interface uses HTTP and its existing cahing mechanisms to
>    achieve CDNI metadata cacheability.
> "
> 
> 
> *** section 3:
> OLD:
> “
> to be retrieved by a dCDN once, even if it is referenced by the CDNI
>    Metadata of multiple Hostnames.
> “
> NEW:
> “
> to be retrieved and stored by a dCDN once, even if it is referenced by the CDNI
>    Metadata of multiple Hostnames or of multiple URI paths.
> 
> 
> *** title of section 3.1
> s/HostIndex, HostMetadata & PathMetadata objects/HostIndex, HostMetadata and PathMetadata objects/
> 
> 
> *** section 3.1:
> s/uCDN's CDNI Metadata data store/uCDN CDNI Metadata data store/
> 
> 
> *** section 3.1:
> OLD:
> “
> It enables surrogates in the dCDN to
>    deterministically discover, on receipt of a User Agent request for
>    content, which other CDNI Metadata objects it requires in order to
>    deliver the requested content.
> “
> NEW:
> “
> It enables the dCDN to
>    deterministically discover, on receipt of a User Agent request for
>    content, which other CDNI Metadata objects it requires in order to
>    deliver the requested content.
> “
> [Rationale: the MI is intended to be used between uCDN and dCDN. It might also be used inside teh dCDN and by surrogate sthemselves, but that is not necessary. So we may want to refer to the MI endpoints as “the uCDN” and “dCDN” (and not the "dCDN Surrogates”)  ]
> 
> 
> *** section 3.1:
> OLD:
> “
> When looking up CDNI Metadata, the downstream CDN looks
>    up the requested Hostname (or IP address) in the HostIndex, 
> “
> NEW:
> “
> When looking up CDNI Metadata, the downstream CDN looks
>    up the requested Hostname (or IP address) against the HostMatch entries in the HostIndex, 
> “
> 
> *** section 3.1:
> OLD:
> “
> Besides containing the default CDNI Metadata for the specified
>    Hostname, HostMetadata and PathMetadata objects may also contain
>    PathMatch objects which in turn contain PathMetadata objects.
> “
> NEW:
> “
> HostMetadata and PathMetadata objects may also contain
>    PathMatch objects which in turn contain PathMetadata objects.
> “
> [Rationale:  the main part of the sentence is applicable to both HostMetadata and PathMetadata, which grammatically suggests that the first part of the sentence is also applicable to both, while it is only applicable to Hostmetadata]
> 
> 
> *** section 3.1:
> s/For the purposes of retrieving CDNI Metadata all/For the purposes of retrieving CDNI Metadata, all/
> 
> 
> *** section 3.1, Table1.
> "The relationships in Figure 1 are summarised in Table 1 below.”
> I think Table 1, contains the exact same information as Figure 1. .i.e., Table 1 does not provide a “summary”. It just shows the same information in a different way. Or am I missing some information in Figure 1 that is not in Table 1?
> I was going to comment that perhaps we could get rid of Table 1, but I can see that it may be worth expressing it in a tabular manner as well, so I am OK to keep Table 1. But you may want to:
> *  tweak the text to say something like:
> "The relationships in Figure 1 are also represented in a tabular format in Table 1 below.”
> * adjust the titles of Figure 1 and Table 1 because it is confusing to have them show teh same information but have different titles. Maybe something like:
> o "Figure 1: Relationships between CDNI Metadata Objects (Diagram Representation)”
> o “Table 1: Relationships between CDNI Metadata Objects (Table Representation)”
> 
> 
> *** section 3.1, Table1
> "Objects it References”
> should this say "Objects it References or Contains” ?
> 
> 
> *** section 3,1: Table 2
> s/A HostMatch object defines a hostname/A HostMatch object defines a hostname (or IP address)/
> 
> 
> 
> *** Section 3.1, Table 2
> for Hostmatch it says "contains or references”
> for HostMetadata it says "contains (or references)”
> you should use the same style (unless there is a reason not to).
> 
> 
> Begin forwarded message:
> 
>> Resent-From: <[email-masked]>
>> From: <[email-masked]>
>> Subject: New Version Notification - draft-ietf-cdni-metadata-06.txt
>> Date: 14 February 2014 22:46:18 CET
>> Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
>> To: <[email-masked]>, <[email-masked]>, <[email-masked]>
>> 
>> 
>> A new version (-06) has been submitted for draft-ietf-cdni-metadata:
>> http://www.ietf.org/internet-drafts/draft-ietf-cdni-metadata-06.txt
>> 
>> 
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/
>> 
>> Diff from previous version:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-metadata-06
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> IETF Secretariat.
>> 
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 22 Apr 2014 15:46:49 +0100

Francois,

Just to confirm (as it might be hard to track from the e-mail chain), Kevin has updated the authors’ working copy of -07 to incorporate all the editorial changes you suggest below.

The only open issue remaining from this batch of comments is the definition of a ‘Do Not Serve’ metadata object. That isn’t purely editorial so needs a bit of discussion amongst the authors but we’ve put an editors note in our working copy of -07 so we don’t forget to cover it.

Ben

On 21 Feb 2014, at 16:34, Francois Le Faucheur (flefauch) <[email-masked]> wrote:

> 
> *** section 3.1: Table 2:
> "A PathMetadata object contains the CDNI GenericMetadata objects”
> Should this say “contains or references”?
> Same comment for “GenericMetadata”?
> Because of the inconsistencies in the description, I guess I am not 100% clear at this stage as to whether it is always possible to "either contain or reference”, or whetehr there are some cases where it “always contains”. Please make sure this is made clear.
> 
> 
> *** section 3.2:
> OLD:
> “
> If the
>   dCDN does not understand or support the property type and the
>   property type is not mandatory to enforce, then the GenericMetadata
>   object may be safely ignored.
> “
> NEW:
> “
> If the
>   dCDN does not understand or support the property type and the
>   property type is not mandatory to enforce, then the GenericMetadata
>   object may be safely ignored and the dCDN MUST process
>   the content request in accordance with the rest of the CDNI metadata.
> “
> 
> 
> *** section 3.2: 
> "
> If the dCDN does not understand
>   or support the property type it is also not going to be able to
>   properly propagate the Metadata for cascaded distribution. 
> “
> This sentence is placed in the middle of the 2nd paragraph while it discusses metadata redistribution which is not the subject of the 2nd paragraph and is fully discussed in the 3rd paragraph. So that sentence should be removed from 2nd paragraph and merged with 3rd paragraph (or removed altogether it it is redundant with 3rd paragraph). 
> 
> 
> *** section 3.2
> s/optimially/optimally/
> 
> 
> ***section 3.2:
> I would suggest capitalizing the two terms you define everywhere to make it clear that these are  very precise terms that you define here. 
> “Mandatory To Enforce” (or “Mandatory-To-Enforce”)
> “Safe To Redistribute” (or “Safe-To-Redistribute”)
> another option coudl to quote the corresponding property names defined later ie “madatory-to-enforce”/“safe-to-redistribute”.
> 
> 
> *** section 3.3:
> OLD:
> “
>      the TimeWindowACL defined in the PathMetadata would override the
>      TimeWindowACL defined in the HostMetadata
> “
> NEW:
> “
>      the TimeWindowACL defined in the PathMetadata would override the
>      TimeWindowACL defined in the HostMetadata for
>      all User Agent requests for content under "example.com/movies"
> “
> 
> 
> *** section 3.3:
> “
> The PathMetadata defined TimeWindowACL would override the
>   TimeWindowACL defined in the HostMetadata for all User Agent requests
>   for movies.
> “
> This seems 100% redundant with the previous example. If this is correct, just remove. If this is not correct, clarify what extra information it brings.
> 
> 
> *** section 3.4:
> “The type
>   SHOULD be descriptive, and MAY be hierarchical to support aggregating
>   groups of properties for the purpose of readability and for avoiding
>   name conflicts between vendor extensions.  A dotted alpha-numeric
>   notation is suggested for human readability.”
> I think all the normative language about metadata types shoudl be moved to the relevant IANA sub-section  (unless we conclude differently in the thread about that question started in the context of cdni-logging). So I’d see all the quoted text above be merged into the appropriate IANA sub-section.   
> 
> *** section 3.4:
> " Metadata types defined by this document are not hierarchical."
> I suggest adding an explanation or example about what you mean by “hierarchical”.
> 
> On 14 Feb 2014, at 22:46, [email-masked] wrote:
> 
>>