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

[Ori Finkelman <[e-mail]>]

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]