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

[Kevin Ma <[e-mail]>]

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 <[e-mail]> wrote:

> 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 <[e-mail]>
> wrote:
>
>> 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 <[e-mail]> 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: <[e-mail]>
>>> 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 <[e-mail]>, Ori Finkelman <
>>> [e-mail]>
>>>
>>>
>>>
>>> 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: [phone] | Mobile: [phone]
>>> | [e-mail]
>>>
>>> _______________________________________________
>>> CDNi mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/cdni
>>>
>>>
>>
>
>
> --
>
> *Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |
> [e-mail]
>