Subject: Re: [CDNi] Comments on draft-ietf-cdni-footprint-capabilities-semantics-09

From: Kevin Ma J <[email-masked]>
Date: Thu, 3 Mar 2016 22:27:50 +0000

Hi Francois,

  Thank you for the review.  I agree with all your suggestions below and have also cleaned up the 2119 language and removed the "federation" language.  I will be uploading a new version shortly.

thanx!

--  Kevin J. Ma

> -----Original Message-----
> From: Francois Le Faucheur [mailto:[email-masked]]
> Sent: Thursday, March 03, 2016 4:03 PM
> To: [email-masked]
> Cc: <[email-masked]>
> Subject: Comments on draft-ietf-cdni-footprint-capabilities-semantics-09
> 
> Dear FCI semantics authors and all,
> 
> 
> As part of the document shepherding, i did a WG chair review of the latest
> version, and have the comments below.
> 
> Cheers
> 
> Francois
> 
> 
> Significant Comment:
> ================
> I think the document needs a clean up of its use of many “musts” and
> “needs” etc.
> 
> In section 4 , “MUST” is used, I believe correctly , e.g. “ therefore
> constitute mandatory capabilities that MUST be supported by the CDNI
> FCI:”.
> 
> But there are also many occurrences in the document of “must”. Most of
> these should probably be simply replaced by “needs to” (where it is
> intended not to mean anything mandatory to implement).
> For example, in section 4, it says "downstream CDN must be able to ...”.
> Similarly, in section 5 it says "the dCDN must be able to …"
> 
> In section 7, it says: "Therefore, any FCI solution protocol must define
>    how the support for optional types of footprint/capabilities will be
>    negotiated between a uCDN and a dCDN that use the particular FCI
>    protocol.”
> I think that should be a MUST.
> And similarly, still in section 7, it says: "any FCI solution protocol
> needs to specify” and I think that should probably be a "MUST specify”.
> 
> 
> Editorial Comments
> ================
> 
> 
> *** Abstract:
> OLD:
> “
> guidelines how
> “
> NEW:
> “
> guidelines on how
> “
> 
> 
> There are MANY occurrences of the terms “federation/federate/federated” in
> the document. Those need to be all removed and replaced simply with
> “interconnected CDNs” or something like that.
> The reason is that “CDN Federation” is a term discussed in section 5.4 of
> the CDNI Framework document (RFC 7336) with a specific meaning that is NOT
> what is intended here.
> 
> 
> 
> 
> *** section 1:
> OLD:
> “
> The uCDN has received
> “
> NEW:
> “
> The uCDN receives
> “
> 
> 
> 
> 
> *** section 1:
> OLD:
> “
> describes footprint and capabilities advertisement as
> “
> NEW:
> “
> describes the Request Routing Interface as
> “
> 
> 
> 
> 
> *** section 1:
> OLD:
> “
> and detail the
> “
> NEW:
> “
> and details the
> “
> 
> 
> *** section 2:
> OLD:
> “
> seek to federate
> “
> NEW:
> “
> seek to interconnect
> “
> 
> 
> *** section 2:
> OLD:
> “
> need be
> “
> NEW:
> “
> need to be
> “
> 
> 
> *** section 2.1:
> OLD:
> “
> topologically closest
> “
> NEW:
> “
> topologically closer
> “
> 
> 
> 
> 
> 
> “*** section 2.4:
> OLD:
> “
> One the other hand
> “
> NEW:
> “
> On the other hand
> “
> 
> 
> 
> 
> “*** section 2.5:
> OLD:
> “
> to be envisioned the main deployments
> “
> NEW:
> “
> to be envisioned in the main deployments
> “
> 
> 
> 
> 
> “*** section 4:
> OLD:
> “
> A 'set of IP-prefixes' must be able
> “
> NEW:
> “
> A 'set of IP-prefixes' MUST be able
> “
> 
> 
> 
> 
> “*** section 4:
> OLD:
> “
> There must also
> “
> NEW:
> “
> There MUST also
> “
> 
> 
> 
> 
> “*** section 4:
> OLD:
> “
> may defined
> “
> NEW:
> “
> may be defined
> “
> 
> 
> “*** section 4:
> OLD:
> “
> [I-D.ietf-cdni-metadata](
> “
> NEW:
> “
> [I-D.ietf-cdni-metadata])
> “
> 
> 
> 
> “*** section 4:
> OLD:
> “
> cases where there is a transitive CDN interconnection
> “
> NEW:
> “
> cases of cascaded CDNs
> “
> 
> 
> *** section 5:
> OLD:
> “
> It is not feasable
> “
> NEW:
> “
> It is not feasible
> “
> 
> 
> “*** section 8.1.2:
> OLD:
> “
> CDNI FCI AcuiqisitionProtocol
> “
> NEW:
> “
> CDNI FCI AcquisitionProtocol
> “
> 
> 
> *** section 9:
> OLD:
> “
> and footprint advertisement objects in content distribution networks.
> “
> NEW:
> “
> and footprint advertisement objects across interconnected CDNs.
> “
> 
> 
> 
> *** section 9:
> OLD:
> “
> CDNi
> “
> NEW:
> “
> CDNI
> “
> 
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 3 Mar 2016 22:03:21 +0100

As part of the document shepherding, i did a WG chair review of the latest version, and have the comments below. 

Cheers

Francois

Significant Comment:
================
I think the document needs a clean up of its use of many “musts” and “needs” etc.

In section 4 , “MUST” is used, I believe correctly , e.g. “ therefore constitute mandatory capabilities that MUST be supported by the CDNI FCI:”.
 
But there are also many occurrences in the document of “must”. Most of these should probably be simply replaced by “needs to” (where it is intended not to mean anything mandatory to implement).
For example, in section 4, it says "downstream CDN must be able to ...”.
Similarly, in section 5 it says "the dCDN must be able to …"

And similarly, still in section 7, it says: "any FCI solution protocol needs to specify” and I think that should probably be a "MUST specify”.

Editorial Comments
================

*** Abstract:
OLD:
“
guidelines how
“
NEW:
“
guidelines on how
“

There are MANY occurrences of the terms “federation/federate/federated” in the document. Those need to be all removed and replaced simply with “interconnected CDNs” or something like that.
The reason is that “CDN Federation” is a term discussed in section 5.4 of the CDNI Framework document (RFC 7336) with a specific meaning that is NOT what is intended here. 

*** section 1:
OLD:
“
The uCDN has received
“
NEW:
“
The uCDN receives
“

*** section 1:
OLD:
“

*** section 1:
OLD:
“
and detail the
“
NEW:
“
and details the
“

*** section 2:
OLD:
“
seek to federate
“
NEW:
“
seek to interconnect
“

*** section 2:
OLD:
“
need be
“
NEW:
“
need to be
“

*** section 2.1:
OLD:
“
topologically closest
“
NEW:
“
topologically closer
“

“*** section 2.4:
OLD:
“
One the other hand
“
NEW:
“
On the other hand
“

“*** section 2.5:
OLD:
“

“*** section 4:
OLD:
“

“*** section 4:
OLD:
“
There must also
“
NEW:
“
There MUST also
“

“*** section 4:
OLD:
“
may defined
“
NEW:
“
may be defined
“

“*** section 4:
OLD:
“

“*** section 4:
OLD:
“

*** section 5:
OLD:
“
It is not feasable
“
NEW:
“
It is not feasible
“

“*** section 8.1.2:
OLD:
“

*** section 9:
OLD:
“

*** section 9:
OLD:
“
CDNi
“
NEW:
“
CDNI
“