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

[Kevin Ma <[e-mail]>]

Hi Nir,

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

Do the semantics of the object matter?  The objects are independent.  I
guess you might want to process content/metadata first, so having them
separated might make stream processing easier?

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

I don't think you can put it in this table, since this table is requesting
registration from IANA, and that value is already registered.  The
alternative would be to register ci-trigger-collection.v2, even though the
message format will be identical to the original ci-trigger-collection,
just to keep everything uniform as ".v2"; and just/optionally add a note to
section 9.1.3 that it is identical to RFC8007 but rev'd for consistency.

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

Section 9.1.1 already covers ci-trigger-command.v2, referencing 5.1.1, so I
think you can remove Section 9.1.3, unless this is for
ci-trigger-collection.v2?

thanx.

--  Kevin J. Ma

On Sat, Jul 24, 2021 at 6:31 PM Nir Sopher <[e-mail]> wrote:

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