Subject: [CDNi] Review of draft-ietf-cdni-control-triggers-02

From: Kevin Ma J <[email-masked]>
Date: Tue, 6 May 2014 22:15:37 +0000

Hi All,

  Per the chairs' request for a detailed review of the triggers draft,
  I've compiled a list of comments below.

thanx.

--  Kevin J. Ma

comments:

- General: imo, an article in front of uCDN/dCDN (i.e., the uCDN/dCDN)
           makes for easier reading.

- General: There are quite a few lower case "must"s (17), "shall"s (14),
           "should"s (7), and "may"s (36) in the document.  Are they all
           intentionally non-normative? 

- section 2: Should cancelling a trigger and removing a trigger status
             be separated in some way?  Using DELETE for both means
             that if I wanted to cancel a trigger, I would have no way
             to get status on the cancelled trigger, since the status
             resource would be removed at the same time, and delete
             does not return a status, per the example in section 7.2.5

- section 2/4.1: In step 2 of figure 1, it mentions authentication as
                 does section 4.1, but section 7 and 9 provide no
                 guidance on either the authentication mechanism or
                 what precisely is being authenticated.  Presumably we
                 are authenticating that it is a known uCDN making the
                 request for metadata/content that is known to be owned
                 by that uCDN?  Should we state that?

                 Do we have a suggestion (e.g., SSL client auth, HTTP
                 basic/digest auth, etc.) for authentication method?

- section 2.1: I found the wording of this sentance a little confusing.

    "If uCDN wishes to invalidate or purge content, then immediately
     preposition replacement content at the same URLs, it must ensure the
     dCDN has completed the invalidate/purge before initiating the
     prepositioning.  If it fails to do that and the requests overlap, and
     dCDN passes the triggers on to a further dCDN in a cascade, that CDN
     may preposition content that has not yet been invalidated/purged in
     its uCDN."

    Perhaps something like:

    "If uCDN wishes to invalidate or purge content, then immediately
     preposition replacement content at the same URLs, it must ensure the
     dCDN and all cascaded dCDNs have completed the invalidate/purge
     before initiating the prepositioning, otherwise, a cascaded dCDN may
     attempt to preposition content that has not yet been invalidated/purged
     in its uCDN."

- section 3: I would break this into two sentances:

    "The dCDN must present a different set of Trigger Status Resources to
     each interconnected uCDN, only Trigger Status Resources belonging to
     a uCDN shall be visible to it."

    i.e.:

    "The dCDN must present a different set of Trigger Status Resources to
     each interconnected uCDN.  Only Trigger Status Resources belonging to
     a uCDN shall be visible to it."

- section 3: This is the first mention of expiry.  Perhaps a reference
             to Section 4.4?

    "This collection lists all
     uCDN triggers that have been accepted by dCDN, and have not yet been
     deleted by uCDN or expired and removed by dCDN."

- section 4.1: These are the first mention of etime and mtime, perhaps
               there should be a reference to Section 5.2, or some
               type of explaination on what etime > mtime means.

               I am not sure about using of etime > mtime as an indicator.
               If mtime < now and etime < now, but still etime > mtime,
               it would seem to imply that the activity may be complete,
               but I don't think that is the intent?

               Should there be some normative language stating that if
               etime > mtime, the uCDN must update the status, and the
               dCDN must update mtime = now and etime > mtime?

    "If dCDN is not able to track triggered activity, it MAY indicate that
     it has undertaken to complete the activity but will not report
     completion or any further errors.  To do this, it must set the
     trigger status to "complete", with an estimated completion time in
     the future ("etime" greater than "mtime")."

- section 4.4: Why 24 hours?  Seems fast?

    "It
     is recommended that Trigger Status Resources are automatically
     deleted 24 hours after they become completed or failed."

- section 4.4: comma after:

    "If any part of the trigger request fails, "

               comma before:

    ", if the trigger is still running for some URLs
     or Patterns in the trigger request."

               perhaps clarify "cascaded" dCDNs:

    "pass a trigger request on to any of its affected cascaded dCDNs"

- section 5.2: AbsoluteTime is a Unix Epoch, so should be UTC.
               I found the phrase "Time is local to dCDN" confusing as
               I first assumed "local" was referencing timezone, but I
               think "local" is just related to unsynchronized clocks?
               Perhaps: "Time is determined by the dCDN"?

- section 5.4: links is a "List of Relationships".  Why not just URLs?
               If the trigger collection can only reference trigger
               statuses, then why does it need typed relationships?
               The use of a relationship here seems overly complex?

               Is relationship standard JSON terminology?  Should there
               be a reference to the acknowledged work of Mike Kelly?

- section 6: There is a note about MI dependency.
             Is it just for PatternMatch?

- section 6.1.6: "ralationship" -> "relationship"

- section 6.1.6/6.1.7: I think it would be helpful to define the
                       Relationship and Link objects the same way as
                       all the other JSON objects, e.g.:

                       How are the keys in the _links dictionary
                       determined?  And how is their meaning known?
                       The key "self" seems to have a specific meaning?
                       It is essentially a reserved keyword?  Are there
                       other reserved keywords (e.g., "Trigger"), and
                       do they have to be registered somewhere?

    Relationship:
      Key: _links
      Description: List of related objects?
      Type: Array of LinkUnions
      Mandatory: Yes

    LinkUnion:
      Key: ???
      Description: List of related objects?
      Type: Array of LinkUnions
      Mandatory: No.

      Key: ???
      Description: related objects?
      Type: Link
      Mandatory: No.

    Link:
      Key: href
      Description: URI of the addressable object being referenced
      Type: URL
      Mandatory: Yes
      
      Key: type
      Description: Type of the referenced object
      Type: MIME Media Type
      Mandatory: No

- section 7: There are no examples with "base" or "links".  I have an
             idea of how "base" might be used, but I don't know what
             the purpoes of "links" is.  Can we add an example?

             "URLs are under control" -> "URLs are under the control"

- section 7.2.1/7.2.2: I don't know where the key "Trigger" came from?
                       Is it derived from some known object, or is it
                       randomly selected (and somehow registered)?

- section 7.2.5: Would there be value in returning the status on delete?

- section 9: In the first sentance below, I interpret "access" as the
             ability to read (GET) a status object or collection.  It
             does not necessarily imply to me who can issue a new
             trigger request?  In the second sentance, it says it can
             only "affect" it's own content, which I guess implies
             that only it can affect it's own content, as another uCDN
             affecting it's content would violate this rule?  Should
             we make that more explicit?

    "The dCDN must ensure that each uCDN only has access to its own
     Trigger Status Resources."

    "The dCDN must ensure that activity triggered by uCDN only affects
     metadata or content originating from that uCDN."

             e.g., update the second sentance to something like:

    "The dCDN must ensure that activity triggered by uCDN only affects
     metadata or content originating from that uCDN, and that no other
     uCDN may trigger activity that affects another uCDN's metadata or
     content."

- random: The mention of only affecting a uCDN's own content made me
          think of the DNS diamond scenario.  Do we believe that the
          Content URLs described in section 5.1.1 are sufficient to
          ensure this, or is there a caveat for the diamond case?

    "The dCDN must ensure that activity triggered by uCDN only affects
     metadata or content originating from that uCDN."

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 7 May 2014 13:31:36 +0000

Hi Kevin,
Thanks much for the review.
Let’s hear from the editors on how to address your comments.
Francois

On 7 May 2014, at 00:15, Kevin Ma J <[email-masked]> wrote:

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