Re: [CDNi] Fwd: New Version Notification for draft-finkelman-cdni-triggers-sva-extensions-00.txt

Hi Ori,

  (as an individual) I think generalizing might be good in this case, as it
changes the protocol itself.

  I don't currently have a better versioning scheme to suggest.  (Ben/Rob?)

  I also cannot come up with a reason to have it outside of the trigger
command.  It feels like it would be better if it was independent, but it
seems simpler to just include it in the trigger command.  I don't have a
good argument for the alternative, so I'm fine with what you've got.
(Ben/Rob?)

  I think "CIT.*" payload types are fine.

  Some comments on the draft:

  - section 2.2:
    "e.g.  HLS/DASH/MSS, DASH templates" -> "e.g., HLSvX, DASHvY, MSSvZ"?

  - section 3.1:
    "a \"trigger\" object" -> "\"trigger\" objects"
    "All other properties of the trigger command are as defined in section
5.1.1 of [RFC8007]." -> "All other properties of the trigger commandstatus
resource are as defined in section 5.1.2 of [RFC8007]."
    "ci-trigger-collection is used with no changes comparing to previous
version." -> "ci-trigger-collection is used with no changes and as defined
in section 5.1.3 of [RFC8007]."

    do you want to also add an example of the trigger status resource
response?

  - section 3.2:
    "the trigger Command applies to" -> "to which the CI/T trigger command
applies"
    "\"metadata.*\", \"content.*\" or \"playlist.urls\"" -> "\"metadata.*\"
or \"content.*\""
    "the CI/T trigger command applies to" -> "to which the CI/T trigger
command applies"
    "\"metadata.*\", \"content.*\" or \"content.playlists\"" ->
"\"metadata.*\" or \"content.*\""
    "and extensions:." -> "and extensions:"

  - section 3.3:
    "Mandatory: No, but at least one of \"metadata.*\", \"content.*\" or
\"playlist.urls\" MUST be present and non-empty." -> "Mandatory: Yes."
    "(name-of-tile]" -> "(name-of-title)"

  - section 3.4:
    "on each one of them" -> "to each one of them"

  - section 3.6.1: If the current dCDN does not understand the command,
does it make sense to propogate that command?  If not, then redistribution
safety is not an issue.

  - section 4.1:
    "the trigger command is relevant for" -> "for which the trigger command
is relevant"
    "must not reside on" -> "must not reside"

  - section 4.2: was the final decision to go with separate commands for
each timezone (as opposed to specifying a timezone-agnostic "local time"
value for regional prepositioning)?

    "content management operation on" -> "content management operations on"
    "used with combination with" -> "used in combination with"
    "defined in Section 4.1 the" -> "defined in Section 4.1, the"
    "using different schedule" -> "using a different schedule"

  - section 5.1: should this be not mandatory to specify, when only version
1 is supported?

  - section 5.2: can this default to none supported and not be mandatory to
specify?

  - section 5.2: can this default to none supported and not be mandatory to
specify?

  - section 6.1.1/6.1.2: "Section 4.1" -> "Section 3.1"?

thanx!

--  Kevin J. Ma

On Thu, Jun 14, 2018 at 5:01 AM, Ori Finkelman <orif@qwilt.com> wrote:

> Dear Colleagues,
> Please note that I have submitted version 00 for trigger extensions drafts.
>
> A few points for discussion:
>
> *Context*
> This document is currently under the context of SVA extensions.
> I think it cam be generalized since there is nothing here which is
> specific only for the SVA needs.
>
>
> *Trigger interface versioning*
> As we are changing the trigger interface, we have chosen to define it
> under version 2 of the interface and explicitly define the CI/T commands
> that are supported by this version.
> The changed commands now have the suffix v2 to their names, to distinguish
> them from the previous version..
> Please see details in section 3 of this document.
> Please let us know if this versioning scheme is acceptable or if other
> versioning scheme is preferable.
>
>
> *Trigger extensions*
> We have chosen to add the array of extension objects within the trigger.v2
> object.
> I am still not sure if it is better to have it within the trigger object,
> or a separate object within the trigger command.
> As I couldn't find a separate use case, other than the trigger I have put
> it in the trigger object, but I really like to get your views about it.
>
> *Trigger extensions registry*
> We have chosen to add trigger extension object names under the CDNI
> payload registry with the name space CIT.
> For example CIT.TimePolicy and CIT.LocationPolicy.
> The other option would be to open a new sub-registry for that.
>
> Thanks,
> Ori
>
>
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: Thu, Jun 14, 2018 at 11:47 AM
> Subject: New Version Notification for draft-finkelman-cdni-triggers-
> sva-extensions-00.txt
> To: Sanjay Mishra <sanjay.mishra@verizon.com>, Ori Finkelman <
> orif@qwilt.com>
>
>
>
> A new version of I-D, draft-finkelman-cdni-triggers-sva-extensions-00.txt
> has been successfully submitted by Ori Finkelman and posted to the
> IETF repository.
>
> Name:           draft-finkelman-cdni-triggers-sva-extensions
> Revision:       00
> Title:          CDNI Triggers Interface SVA Extensions
> Document date:  2018-06-13
> Group:          Individual Submission
> Pages:          26
> URL:            https://www.ietf.org/internet-
> drafts/draft-finkelman-cdni-triggers-sva-extensions-00.txt
> Status:         https://datatracker.ietf.org/
> doc/draft-finkelman-cdni-triggers-sva-extensions/
> Htmlized:       https://tools.ietf.org/html/d
> raft-finkelman-cdni-triggers-sva-extensions-00
> Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-finkelman-cdni-triggers-sva-extensions
>
>
> Abstract:
>    The Open Caching working group of the Streaming Video Alliance is
>    focused on the delegation of video delivery request from commercial
>    CDNs to a caching layer at the ISP.  In that aspect, Open Caching is
>    a specific use case of CDNI, where the commercial CDN is the upstream
>    CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN).
>
>
>
>
>
> 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.
>
> The IETF Secretariat
>
>
>
>
> --
>
> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
> orif@qwilt.com
>
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni
>
>