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

[Nir Sopher <[e-mail]>]

Hi Kevin and all,

Following Kevin's comments we now released a second version of the draft
<https://datatracker.ietf.org/doc/draft-sopher-cdni-ci-triggers-rfc8007bis/02/>
-
dealing mostly with typos and such.
AIs yet to be addressed:

   1. 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?
   *Status*: Note that to preserve privacy it is up to the tCDN to decide
   whether it puts his PID or the dCDN's PID.
   *TBD*: Relate to the question whether PIDs are unique or discernible by
   the uCDN
   2. 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?
   *Status*: We will look into it
   3. Section 5.2.8.1: do we think triggers need safe-to-redistribute?  do
   we envision trigger extensions that are modified by tCDNs?
   *Status*: Should be further discussed.
   We have started to look into it. We currently do not envision trigger
   modifications by the tCDN.
   However, shouldn't the "safe-to-redistribute" field be added as a good
   practice?
   4. Section 9.1: is "ci-trigger-collection" changing?  if not, it doesn't
   need to be in the table?
   *Status*: We would define a "v2" of the collection object
   5. Errata: https://www.rfc-editor.org/errata/eid5064
   *Status: *We would take the opportunity to add both trigger 's
   "canceling" and "deletion" examples.

I would prefer to further address these issues once we create a new WG
draft.

Thanks,
Nir

On Tue, Jul 27, 2021 at 3:40 AM Kevin Ma <[e-mail]> wrote:

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