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

[Kevin Ma <[e-mail]>]

Hi Nir,

  I don't think we want a new registry.  The purpose of the payload type
registry was so that we could have a single registry for all json
object/message types.

thanx.

--  Kevin J. Ma

On Mon, Jul 26, 2021 at 4:29 AM Nir Sopher <[e-mail]> wrote:

> Hi Kevin,
>
> I further mean to open a new registry all together. CI/T.V2 registry.
>
> Nir
>
> On Sun, Jul 25, 2021 at 10:17 PM Kevin Ma <[e-mail]>
> wrote:
>
>> Hi Nir,
>>
>> > Maybe instead of defining "ci.trigger.v2" and "ci.error.v2" etc., we
>> should define "ci.v2" . I.e. "ci.v2.trigger" .... replacing all objects and
>> that's it
>>
>>   I'm not entirely sure I follow.  Is this just moving the "v2" to the
>> front, but still reregistering all payload types?  I don't have an issue
>> with that.
>>
>> thanx.
>>
>> --  Kevin J. Ma
>>
>> On Sun, Jul 25, 2021 at 4:48 AM Nir Sopher <[e-mail]> wrote:
>>
>>> Inline,
>>> Thanks,
>>> Nir
>>>
>>> On Sun, Jul 25, 2021 at 4:32 AM Kevin Ma <[e-mail]>
>>> wrote:
>>>
>>>> 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?
>>>>
>>> +1
>>>
>>>>
>>>> > > - 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.
>>>>
>>>
>>> Maybe instead of defining "ci.trigger.v2" and "ci.error.v2" etc., we
>>> should define "ci.v2" . I.e. "ci.v2.trigger" .... replacing all objects and
>>> that's it.
>>>
>>>>
>>>> > > - 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?
>>>>
>>> Missed that, you are correct.
>>> It should have been "collection".
>>>
>>>>
>>>> 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
>>>>>>>
>>>>>>