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

From: Kevin Ma <[email-masked]>
Date: Mon, 9 Jul 2018 01:43:33 -0400

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 <[email-masked]> 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: <[email-masked]>
> 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 <[email-masked]>, Ori Finkelman <
> [email-masked]>
>
>
>
> 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 |
> [email-masked]
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
>
>

---

From: Ori Finkelman <[email-masked]>
Date: Mon, 9 Jul 2018 17:41:45 +0300

Hi Kevin,
Thanks for the review and thorough feedback.
I have updated your comments and they will appear in the next draft.

Referring to your questions:

============
  + section 3.6.1
I think there may be such cases in which it is relevant to redistribute
even if an extension object is not understood by a certain dCDN.
For example, let's imagine a best effort feature for pre-positioning only
the 4 highest qualities of a specific content. Suppose someone defines such
an extension object.
If, for example a certain dCDN does not understand it, it is still safe to
execute and redistribute.  This is very much like the case for metadata,
isn't it ?
Let's further discuss by email or in the CDNI meeting.

============
+ section 4.2
The general sentiment was to avoid "local-time" and use location policy in
conjunction with time policy to achieve this goal.
I am happy to open it as I think local time is more simple (but I agree
less flexible as it doesn't allow the dCDN to use its best judgment).

============
+ section 5.1: should this be not mandatory to specify, when only version 1
is supported?
The "Mandatory: Yes." refers to the property "versions" within the
FCI,TriggerVersions capability object. I think that if the object is
advertised then some versions must be included.
If only version 1 is supported the dCDN can avoid advertising this object.
If you think it's good to have the option to advertise the object with an
empty list where only version 1 is supported, I will add it.

============
+ section 5.2: can this default to none supported and not be mandatory to
specify?
Shouldn't "none" be expressed by not advertising the
FCI.TriggerPlaylistProtocol object, instead of advertising it with an empty
protocol list ?

============
+ section 5.3: can this default to none supported and not be mandatory to
specify?
The "extensions" property within the trigger.v2 was defined as optional in
section 3.2, if there are no extensions one can avoid this property.
Do you think we should also allow an empty list while the property is added
?

Thanks,
Ori

On Mon, Jul 9, 2018 at 8:43 AM, Kevin Ma <[email-masked]> wrote:

> Hi Ori,
>
>   (as an individual) I think generalizing might be good in this case, as
> it changes the protocol itself.
>
>     "\"metadata.*\", \"content.*\" or \"playlist.urls\"" ->
>     "the trigger command is relevant for" -> "for which the trigger
> command is relevant"
>   - 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?
>
>> The changed commands now have the suffix v2 to their names, to
>> distinguish them from the previous version..
>> We have chosen to add the array of extension objects within the
>> trigger.v2 object.

--

---

From: Kevin Ma <[email-masked]>
Date: Tue, 10 Jul 2018 22:39:07 -0400

Hi Ori,

> imagine a best effort feature for pre-positioning only the 4 highest
qualities of a specific content. Suppose someone defines such an extension
object. If, for example a certain dCDN does not understand it, it is still
safe to execute and redistribute.  This is very much like the case for
metadata, isn't it ?

Agreed.  This makes sense to me.

> The general sentiment was to avoid "local-time" and use location policy
in conjunction with time policy to achieve this goal.  I am happy to open
it as I think local time is more simple

I agree that "localtime" is much simpler.  With the right text and
representation, I think it should be simple to understand.

> If only version 1 is supported the dCDN can avoid advertising this object.

My concern with not advertising is that we don't yet have a protocol for
sending FCI messages...  My original FCI draft anticipated FCI supporting
update messages, i.e., if a capability is in the message, then it should
replace any previously cached value, however, if the capability is not in a
message, then it's a noop wrt that capability, and the existing cached
value can continue to be used.  So, if a dCDN advertised v2, but then
wanted to downgrade to v1, then it would need to send FCI.TriggerVersion
with an empty list (or a v1 list), which could be simplified to omitting
the list altogether.

This FCI update concern applies to FCI.TriggerPlaylistProtocol and
FCI.TriggerGenericExtension
as well.

So, to support updates, I think using empty lists (or no list at all) is
necessary.  If, however, the FCI advertisement is always a full list of all
known capabilities, then i agree that omitting the capability would be a
reasonable approach to advertising a lack of capabilities.

thanx!

--  Kevin J. Ma

On Mon, Jul 9, 2018 at 10:41 AM, Ori Finkelman <[email-masked]> wrote:

> + section 5.1: should this be not mandatory to specify, when only version
> 1 is supported?
> Do you think we should also allow an empty list while the property is
> added ?
>
>
> Thanks,
> Ori
>
>
>
>>     "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]."
>>     "the trigger Command applies to" -> "to which the CI/T trigger
>> command applies"
>>> 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.
>>>
>>> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189
>>> | [email-masked]
>>>

---

From: Ori Finkelman <[email-masked]>
Date: Wed, 11 Jul 2018 10:03:35 +0300

Hi Kevin,
+ As for the localtime, let's discuss it in the CDNI meeting, I am happy to
add it, let's just see we have a consensus on that.
+ As for empty capability lists, your point is valid, I will update the
draft accordingly and define the defaults for each case.

Thanks,
Ori

On Wed, Jul 11, 2018 at 5:39 AM, Kevin Ma <[email-masked]> wrote:

> This FCI update concern applies to FCI.TriggerPlaylistProtocol and FCI.TriggerGenericExtension
> as well.
>
> necessary.  If, however, the FCI advertisement is always a full list of
> all known capabilities, then i agree that omitting the capability would be
> a reasonable approach to advertising a lack of capabilities.
>
> thanx!
>
> --  Kevin J. Ma
>
>> If, for example a certain dCDN does not understand it, it is still safe
>> to execute and redistribute.  This is very much like the case for metadata,
>> isn't it ?
>> in conjunction with time policy to achieve this goal.
>> The "extensions" property within the trigger.v2 was defined as optional
>> in section 3.2, if there are no extensions one can avoid this property.

--