Re: [CDNi] CDNi Control-Interface / Trigger: content & metadata selection lists

[Nir Sopher <[e-mail]>]

Hi Kevin,

I certainly agree that the metadata and content lists should be merged into
a single GenericTriggerObjects list.
I'm not sure however regarding the merging the extensions list as well - as
the extensions do not specify which content to operate on but how to
operate.
Maybe this list should be called "GenericTriggerInstructions".
See examples attached.

Thank you for the comments.
See my reply inline,

Thanks,
Nir

On Sat, Jul 24, 2021 at 7:55 AM Kevin Ma <[e-mail]> wrote:

> Hi Nir,
>
>   (As an individual) Would another option be to just have a single list of
> GenericTriggerObjects that could contain content, metadata, or extensions?
>
>   Some other comments on the draft below.
>
> thanx.
>
> --  Kevin J. Ma
>
> Comments:
>
> - There are existing errata on RFC8007, we should probably work them into
> this updated spec:
> https://www.rfc-editor.org/errata_search.php?rfc=8007&rec_status=0
>
NBS: Ack

> - Section 4.8.1: "occured" -> "occurred"
>
- Section 4.8.1: are there privacy concerns with propagating the PID?  Does
> the uCDN really need to know the ultimate dCDN, given that we are allowing
> the tCDN to decide whether to shield the dCDN?  Also, is there any
> guarantee that the PIDs are unique or discernible by the uCDN?
>
NBS: We'll further discuss it and reply. Note that to preserve privacy it
is up to the tCDN to decide whether it puts his PID or the dCDN's PID

> - Section 5.2.7/9.4: can we use media types, e.g., "application/dash+xml"
> or "application/vnd.apple.mpegurl", rather than defining custom values?
>
NBS: I'll look into it

> - Section 5.2.8.1: do we think triggers need safe-to-redistribute?  do we
> envision trigger extensions that are modified by tCDNs?
>
NBS: We'll further discuss it and reply

> - Section 5.2.8.1: ".." -> "."
> - Section 6.1: "region," -> "region"
>
- Section 9.1: is "ci-trigger-collection" changing?  if not, it doesn't
> need to be in the table?
>
NBS: It was already defined in RFC 8007. Should we mention it (now without
registering it) just for completeness?

> - Section 9.1.3: is this for trigger collection, not trigger command?  can
> be removed?
>
NBS: It is a command. The reference within the section should be fixed to
point at 5.1.1 and not 5.1.3

>
>
>
>
> On Tue, Jul 20, 2021 at 12:49 AM Nir Sopher <[e-mail]> wrote:
>
>> Hi,
>>
>> As you may know, CDNi WG I-D for control triggers extensions
>> <https://datatracker.ietf.org/doc/html/draft-ietf-cdni-triggers-extensions> extends
>> RFC-8007 <https://datatracker.ietf.org/doc/html/rfc8007> (CDNi
>> control-interface/triggers) - including the addition of 2 content-selection
>> methods as properties to the trigger object: content.regex and
>> content.playlists.
>> IIUC, every such addition of a property to the trigger object, requires
>> the redefinition of the object - in this case creating a "v2" trigger
>> object.
>>
>> We are now working on merging this I-D into RFC-8007 - aiming to  create
>> the 2nd edition of the CDNi Control Interface RFC.
>> During this process we came up with an idea that instead of redefining
>> the trigger object over and over again, we can just add a "content"
>> selection list and a "metadata" selection list to the trigger object.
>>
>> Following the suggestion, the trigger.V2 object would have the following
>> properties (in green, the new lists. In red - properties that we may
>> consider to remove):
>>
>>    - type
>>    - content: list of content-selection objects (TBD: type and values)
>>    - metadata: list of metadata-selection (TBD: type and values)
>>    - metadata.urls
>>    - content.urls
>>    - content.ccid
>>    - metadata.patterns
>>    - content.patterns
>>    - content.regexs
>>    - content.playlists
>>    - extensions
>>
>> The content/metadata selection method types would have designated
>> registries and a dCDN should be able to publish via the FCI which methods
>> are supported (using designated capabilities). Hence, every future
>> content/metadata selection method would only require the addition of the
>> proper types to the registry.
>>
>> Please share your thoughts.
>>
>> Thanks,
>> Nir
>>
>