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

From: Nir Sopher <[email-masked]>
Date: Tue, 20 Jul 2021 07:49:07 +0300

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

---

From: Kevin Ma <[email-masked]>
Date: Sat, 24 Jul 2021 00:55:04 -0400

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
- 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?
- 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?
- Section 5.2.8.1: do we think triggers need safe-to-redistribute?  do we
envision trigger extensions that are modified by tCDNs?
- 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?
- Section 9.1.3: is this for trigger collection, not trigger command?  can
be removed?

On Tue, Jul 20, 2021 at 12:49 AM Nir Sopher <[email-masked]> wrote:

> <https://datatracker.ietf.org/doc/html/draft-ietf-cdni-triggers-extensions> extends
> 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.
>

---

From: Nir Sopher <[email-masked]>
Date: Sun, 25 Jul 2021 01:31:31 +0300

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

> https://www.rfc-editor.org/errata_search.php?rfc=8007&rec_status=0
NBS: Ack

> 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

> or "application/vnd.apple.mpegurl", rather than defining custom values?
NBS: I'll look into it

> envision trigger extensions that are modified by tCDNs?
NBS: We'll further discuss it and reply

> 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
NBS: It is a command. The reference within the section should be fixed to
point at 5.1.1 and not 5.1.3

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

---

From: Kevin Ma <[email-masked]>
Date: Sat, 24 Jul 2021 21:31:53 -0400

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?

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?

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 <[email-masked]> 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.
>>   (As an individual) Would another option be to just have a single list
>> of GenericTriggerObjects that could contain content, metadata, or
>> extensions?
>>
> - 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
>> - Section 5.2.8.1: do we think triggers need safe-to-redistribute?  do
>> we envision trigger extensions that are modified by tCDNs?
>>
>> - Section 9.1.3: is this for trigger collection, not trigger command?
>> can be removed?
>>

---

From: Nir Sopher <[email-masked]>
Date: Sun, 25 Jul 2021 11:48:15 +0300

Inline,
Thanks,
Nir

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

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.

> > 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
Missed that, you are correct.
It should have been "collection".

>>> - There are existing errata on RFC8007, we should probably work them
>>> into this updated spec:
>>>> We are now working on merging this I-D into RFC-8007 - aiming to
>>>> create the 2nd edition of the CDNi Control Interface RFC.
>>>> 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

---

From: Kevin Ma <[email-masked]>
Date: Sun, 25 Jul 2021 15:17:07 -0400

Hi Nir,

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 <[email-masked]> wrote:

>> > 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.
>>
>> 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,
>> > > - Section 9.1.3: is this for trigger collection, not trigger
>> command?  can be removed?
>>> 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
>>>
>>>>> 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.
>>>>>

---

From: Nir Sopher <[email-masked]>
Date: Mon, 26 Jul 2021 11:29:09 +0300

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 <[email-masked]> wrote:

>>> 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
>>>>>   (As an individual) Would another option be to just have a single
>>>>> list of GenericTriggerObjects that could contain content, metadata, or
>>>>> extensions?
>>>>>
>>>>> - Section 5.2.8.1: do we think triggers need safe-to-redistribute?
>>>>> do we envision trigger extensions that are modified by tCDNs?
>>>>>
>>>>>> 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.
>>>>>>

---

From: Kevin Ma <[email-masked]>
Date: Mon, 26 Jul 2021 20:39:52 -0400

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 <[email-masked]> wrote:

>>>> > 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.
>>>>
>>>> > NBS: It is a command. The reference within the section should be
>>>> fixed to point at 5.1.1 and not 5.1.3
>>>>

---

From: Nir Sopher <[email-masked]>
Date: Wed, 28 Jul 2021 23:13:34 +0300

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 <[email-masked]> wrote:

>>>>> Do the semantics of the object matter?  The objects are independent.
>>>>> I guess you might want to process content/metadata first, so having them
>>>>>> I certainly agree that the metadata and content lists should be
>>>>>> merged into a single GenericTriggerObjects list.
>>>>>> - 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
>>>>>>