Subject: Re: [CDNi] Start of Working Group Last Call on "draft-ietf-cdni-control-triggers-04"

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 10 Nov 2014 13:12:16 +0000

Hi Rob, Ben,

I’ve reviewed the latest version of the draft-ietf-cdni-control-triggers document. (Sorry for missing the deadline by a day ;) )

In general, I think the document is in a good state and almost ready to be sent to the IESG. I’ve got a few comments:

- In section 5.2.2, it says under ‘purge’,  “After servicing the request, the specified data MUST NOT be held on the dCDN.” I think we agree on what purge should do, but this sentence might not be the best representation of that. Maybe it would be better to formulate it along the lines of ‘After servicing the request, the specified data MUST be invalidated on the dCDN”, or even better “After servicing the request, the dCDN MUST reject any future requests for the specified data”.
- On the same section: do you want to say anything about ongoing transfers of the specified data? Are these to be terminated?
- The security considerations section mostly discusses solutions, but doesn’t present the potential risks. As an example: While I appreciate you mandating the dCDN to support TLS, the fact that you don’t mandate its use I think requires you to at least list the potential risks of not doing so. I imagine having some entity sends illegitimate purge requests can have quite an impact on the CDNs, and it wouldn’t hurt pointing out these issues. Especially since this not only impacts the dCDN, but the uCDN as well, since the dCDN will have the re-fetch to content. The same goes for having a third party send metadata invalidation requests.

Best regards,

Ray

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday 27 October 2014 13:56
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [CDNi] Start of Working Group Last Call on "draft-ietf-cdni-control-triggers-04"

All,

In accordance with our Toronto agreement, this is the start of a two-week Working Group Last Call on draft-ietf-cdni-control-triggers-04:
https://datatracker.ietf.org/doc/draft-ietf-cdni-control-triggers/

This Working Group Last Call will end on 9 Nov 2014.
Please send your comments to the CDNI Mailing List.

Francois & Daryl
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 10 Nov 2014 21:01:32 +0000

Folks,

(as an individual contributor)

Below are my belated comments.
I hope this is useful.

Francois

*** 2:
“
A trigger, sent from the uCDN to the dCDN, is a request for the dCDN
   to do some work relating to data originating from the uCDN.
“
well, when the trigger applies to content, the content may originate from the uCDN or it may originate from somewhere else.
How about the following? :
“
A trigger, sent from the uCDN to the dCDN, is a request for the dCDN
   to do some work relating to data associated with content requests originating from the uCDN.
“

*** 2:
"The dCDN maintains a collection of Trigger Status Resources for each
   uCDN, each uCDN only has access to its own collection and the
   location of that collection is shared when CDN interconnection is
   established.”
Should we prevent a pair of uCDN and dCDN to use more than 1 collection?
for example, do we want to prevent that a dCDN offers a separate collection for separate “CI endpoints” within the uCDN?
I think we don’t need to prevent that.
So perhaps rephrase into:
"The dCDN maintains (at least) one collection of Trigger Status Resources for each
   uCDN. Each uCDN only has access to its own collection(s) and the
   location of that(these) collection(s) is(are) shared when CDN interconnection is
   established.”

*** 2:
"  Invalidate and purge triggers MUST be applied to all data acquired
   before the trigger was created in the dCDN.  The dCDN MAY apply the triggers to data acquired after trigger creation.”
Phrased this way with an RFC2119 “MAY” it sounds like this is a nice option that the dCDN may elect to support. I believe this is actually something that is undesirable but cannot always be avoided. I think the wording should be tweaked to indicate that.
Perhaps:
"The dCDN SHOULD aim at not applying the invalidate and purge triggers to data acquired after trigger creation, but this may not always be achievable so the uCDN cannot count pn that.”

*** 2:
" 4.  The uCDN can repeatedly poll the Trigger Status Resource in the
       dCDN.”
how about:
" 4.  The uCDN can poll, possibly repeatedly, the Trigger Status Resource in the
       dCDN.”

*** 2.2:
For a reader going through the document the first time, this is a little difficult to follow because all the status (“complete”, “processed” etc) have not yet been defined. One solution may be to include a forward reference towards the section where those are precisely defined.

*** 3:
“The dCDN could, for
   example, achieve this by offering different collection URLs to each
   uCDN, or by filtering the response based on the client uCDN. "
“or” —> "and/or"
also, I don’t think “client uCDN” is very clear. So how about:
“The dCDN could, for
   example, achieve this by offering different collection URLs to each
   uCDN, and/or by filtering the response based on the uCDN to which the HTTP client isseuing the CI/T command is associated with. “

*** 4:
OLD:
"The only representation specified in this document is JSON, [RFC7159].”
NEW:
"The only representation specified in this document is JSON, [RFC7159] and MUST be supported by the uCDN and dCDN."

*** 4.1:
OLD:
"and a resource MUST NOT be created on the dCDN”
NEW:
"and a Trigger Status Resource MUST NOT be created on the dCDN”
BTW, I think there are a few other places where the same change shoudl be made; can you check out throughout the doc?

*** 4.1:
"The HTTP response to the dCDN MUST have status code 201
   and the URI of the Trigger Status Resource in the Location header
   field.”
woudl read better as:
“
The HTTP response to the dCDN MUST have status code 201
   and MUST convey the URI of the Trigger Status Resource in the Location header
   field.

*** 4.1:
OLD:
" Once a Trigger Status Resource has been created the dCDN MUST NOT re-
   use its location, even after that resource has been removed.”
NEW:
" Once a Trigger Status Resource has been created the dCDN MUST NOT re-
   use its URI, even after that resource has been removed.”

*** 4.1:
" The "trigger" property of the Trigger Status Resource contains the
   Trigger Specification posted in the body of the CI/T Command. “
Again for a 1st time reader this is a little difficult to follow because “trigger property” and “Trigger Specification” have never been defined.
I think the best solution woudl be to use a generic description like “The Trigger Status Resource will convey a specification of the trigger” or  “The Trigger Status Resource will convey all the information characterizing the trigger” or something like that.
Another solution woudl be top include forward references to later sections, but that woudl be more difficult to follow.

*** 4.1:
" If the dCDN is not able to track the execution of triggered activity,…”
The text just says what the dCDN ought to do when it can track and when it cannot. I think we want to convey the message that the dCDN should track whenever it is possible.
Can you add a sentence to that effect? probably a “SHOULD”.

*** 4.3:
"The uCDN should respond to that command appropriately”
Why is this not a “MUST” (or at least a SHOULD)?
Also, I think this shoudl say “dCDN” and not “uCDN"

*** 4.3:
" if cancellation is not supported by the dCDN."
So is “cancellation” an "optionnal to implement" feature of the interface? if yes, you need to make that much clearer.
I assume everything else is "mandatory to implement" (eg delete) but making one bit optional (ie cancel) now sort of begs the question. Please ensure this is 100% clear.
Actually I saw later in my review that filtered collections are optional-to-implement. So, can you make sure that this is also clear?

*** 4.3:
OLD:
"does not however guarantee that not activity is started”
NEW:
"does not however guarantee that the corresponding activity will not be started”

*** 4.4:
OLD:
“Subsequent requests to GET the deleted resource SHOULD fail.”
NEW:
“Subsequent requests to GET the deleted resource SHOULD be rejected by the dCDN with an HTTP error.”
Also, why is this not a MUST?

*** 4.4:
"If an "active" or "processed" Trigger Status Resource is deleted, the
   dCDN MAY stop processing the triggered activity. “
Why is this not a SHOULD?

*** 4.5:
OLD:
" It is recommended that Trigger Status Resources are not
   automatically deleted for at least 24 hours after they become
   "complete", "processed", "failed" or "cancelled”.”
NEW:
" It is RECOMMENDED that Trigger Status Resources are not
   automatically deleted by the dCDN for at least 24 hours after they become
   "complete", "processed", "failed" or "cancelled”.”

*** 4.5:
OLD:
"   To ensure it is able to get the status of its completed and failed
   triggers, it is recommended that the uCDN's polling interval is less
   than the time after which records for completed activity will be
   deleted.”
NEW:
"   To ensure it is able to get the status of its completed and failed
   triggers, it is RECOMMENDED that the uCDN polling interval is less
   than the time after which records for completed activity will be
   deleted.”

*** 4.6:
OLD:
"the characters AS followed by the CDN Provider's AS number,”
NEW:
"the two characters “AS" followed by the CDN Provider's Autonomous System number,”

*** 4.6:
some CDN Provider may own multiple ASes. I suggest you add a statement that in such a case, the same AS nb be used in all messages from that CDN Provider (unless the CDN is actually operating as multiple distincts CDNs).

*** 5:
" Names in JSON are case sensitive and therefore the names and literal
   values specified here MUST always use lower-case.”
the fact that JSON is case sensitive does not require that CI uses lower case. It just require that cases are used carefully.
So how about:
" Names in JSON are case sensitive. The names and literal
   values specified in the present document MUST always use lower-case.”

*** 5:
"Unrecognised name/value pairs in JSON objects SHOULD NOT be treated
   as an error by either the uCDN or dCDN.“
Please indicate how they should be treated then.

*** 5.1.1
“A JSON array of …”
Does the term “array” have a completely specified meaning?

*** 5.1.3: coll-all, coll-pending etc.
"Mandatory: Links to filtered collections are mandatory in the
         collection of all Trigger Status Resources, if the dCDN
         implements the filtered collections.  Otherwise, optional.”
I think the intention is that links to ALL the filtered collections are mandatory in that case. If correct, please make that clear.

*** 5.1.3: cdn-id:
"Mandatory: Only in the collection of all Trigger Status
         Resources, if the dCDN implements the filtered collections.
         Optional in the filtered collections.”
Why is the presence of cdn-id tied to the support of filtered collections?

*** 6.1.1 and 6.1.2
you use the phrase “AllTriggers” which is not defined or used anywhere else.
How about just saying “the collection of Trigger Status Resources” , or the “(non-filtered) collection of Trigger Status Resources”

*** 6.1.2:
the text says “case-insensitive matching” while the JSON encoding sys ""case-sensitive" : true”. Is this normal?

*** 6.2.1:
"The uCDN can fetch the set of all the triggers ...”
probably better say :
"The uCDN can fetch the whole collection of Trigger Status Resources …”
I think there are a few occurences where the text uses “triggers” instead of “Trigger Status Resources”, this could be cleaned up.

*** “6.2.2 Filtered Collections of Triggers”
this should read:
“6.2.2 Filtered Collections of Trigger Status Resources”

*** "6.2.3.  Trigger Status Resources”
this could read:
"6.2.3.  Individual Trigger Status Resources”

*** "6.2.5.  Removing a Trigger”
This mixes “removing”, “cancelling” and “deleting”. I think this discusses a delete. So all the wording shoudl be aligned to “delete"

*** 8.1 :
" A CI/T dCDN server implementation MUST support TLS transport for HTTP
   (https) as per [RFC2818]. “
I think the  CI/T uCDN server implementation MUST also support TLS.

*** throughout the document:
There is a fairly loose use of the words “command”, “request”, “trigger”, ...
eg section 2:
"The uCDN triggers action in the dCDN by posting a CI/T Command “
eg section 4:
" Requests are made over HTTP"
I think this could be tightened up.

On 27 Oct 2014, at 02:56, Francois Le Faucheur (flefauch) <[email-masked]<mailto:[email-masked]>> wrote:

All,

Francois & Daryl
_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni