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

[Ori Finkelman <[e-mail]>]

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

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


-- 

*Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |
[e-mail]