Subject: [CDNi] I-D Action: draft-ietf-cdni-control-triggers-05.txt

From: [email-masked]
Date: Mon, 29 Dec 2014 03:46:47 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF.

        Title           : CDNI Control Interface / Triggers
        Authors         : Rob Murray
                          Ben Niven-Jenkins
	Filename        : draft-ietf-cdni-control-triggers-05.txt
	Pages           : 42
	Date            : 2014-12-29

Abstract:
   This document describes the part of the CDN Interconnection Control
   Interface that allows a CDN to trigger activity in an interconnected
   CDN that is configured to deliver content on its behalf.  The
   upstream CDN can use this mechanism to request that the downstream
   CDN pre-positions metadata or content, or that it invalidates or
   purges metadata or content.  The upstream CDN can monitor the status
   of activity that it has triggered in the downstream CDN.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-cdni-control-triggers/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-cdni-control-triggers-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-control-triggers-05

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Rob Murray <[email-masked]>
Date: Mon, 29 Dec 2014 11:51:45 +0000

Hi all, I've posted a new version of the Triggers draft to address comments from Ray and Francois - detailed replies to those two sets of comments are below.

Cheers,
Rob.

> On 10 Nov 2014, at 13:12, Brandenburg, R. (Ray) van <[email-masked]> wrote:
> 
> 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”.   

Invalidate and purge are different - in section 2 it says ...

  - invalidate - used to instruct the dCDN to revalidate specific metadata or content before re-using it.
  - purge - used to instruct the dCDN to delete specific metadata or content.

So, for purge, "the specified data MUST be invalidated on the dCDN" wouldn't be what I intended - the data is actually supposed to be deleted.

Similarly when content is purged - I don't think "the dCDN MUST reject any future requests for the specified data" would be quite right... the dCDN shouldn't just reject requests, it should attempt to re-acquire from the uCDN.

So I've added "(the dCDN should re-acquire the metadata or content from uCDN if it needs it)." to section 5.2.2 - does that cover it?

> - On the same section: do you want to say anything about ongoing transfers of the specified data? Are these to be terminated?

I've added this to section 2.1 "Timing of Triggered Activity" ...

"Because the CI/T Command timing is under the dCDN's control, the dCDN implementation can choose whether to apply CI/T invalidate and purge commands to content acquisition that has already started when the command is received."

> - 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. 

Added "This is intended to prevent unauthorised users from generating unnecessary load in dCDN or uCDN due to revalidation, reacquisition, or unnecessary acquisition."

====

> On 10 Nov 2014, at 21:01, Francois Le Faucheur (flefauch) <[email-masked]> wrote:
> 
> 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.
> “

Done.

> *** 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.”

Done.

> *** 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.”

Done.

(Worded as "The dCDN SHOULD NOT apply the invalidate and purge triggers to data acquired after trigger creation, but this may not always be achievable so the uCDN cannot count on 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.”

Done.

> *** 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.

Added  a ref as suggested.

> *** 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. “

Done.

(Worded as "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 with which the HTTP client is associated.".)

> *** 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."

Done.

> *** 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?

Done (in several places).

> *** 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.

Done.

> *** 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.”

Done.

> *** 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.

Done - merged your general wording in to the previous paragraph, and moved the detail to section 5.1.2 where the Trigger Status Resource is defined.

> *** 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”.

Done (as 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"

uCDN -> dCDN, and added MUST.

> *** 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? 

Done - I think, but let me know if it's still not clear enough...

I've added "Cancellation of triggered activity is optional-to-implement in the dCDN." to section 4.3.

The filtered collections already had "the dCDN SHOULD also maintain collections representing filtered views...", I've added "These filtered collections are optional-to-implement but, if implemented, the dCDN MUST...".

> *** 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”

Done.

> *** 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?

Done, and MUSTed.

> *** 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?

SHOULDed.

> *** 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”.”

Done.

> *** 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.”

Done.

> *** 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,”

Done.

> *** 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).

Added "If the CDN provider has multiple Autonomous Systems, the same AS number SHOULD be used in all messages from that CDN provider (unless there are multiple distinct 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.”

Done.

> *** 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.

Added "They SHOULD be ignored in the processing, and passed on by dCDN to any further dCDNs in a cascade.".

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

I believe so, it's a JSON term defined in section 5 of RFC 7159 ... do you think it needs a specific reference?

> *** 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.

Done.

> *** 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?

It has to be there at least once ... putting it in the filtered collections is a bit of a waste of space, but possibly useful for a human reader. It might be slightly easier to implement all the collections with the same set of properties - so I made it optional.

I've added "Optional in the filtered collections (the uCDN can always find the dCDN's cdn-id in the collection of all Trigger Status Resources, but the dCDN can choose to repeat that information in its implementation 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”

Done.

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

A mistake (so fairly normal!), fixed in the text ... the metadata match is case insensitive, the content match is case sensitive.

> *** 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.

Done, in a few places.

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

Done.

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

Done.

> *** "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"

Done.

> *** 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.

Fixed.

> *** 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.

Done.

=====

> On 29 Dec 2014, at 11:46, [email-masked] wrote:
> 
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni