Re: [CDNi] RFC-8007bis - Generic Trigger Object Selector - Starting a Discussion

[Kevin Ma <[e-mail]>]

Hi Nir,

  (As an individual) Great set of questions.  Sorry for the delayed
response.

  1) I think the intent was an additive semantic, e.g., if I want to purge
the content and the metadata associated with the content, I could do it
with a single trigger request specifying both metadata.X and content.Y.  (I
think this is implied in section 2.3 where it says "MUST NOT be reported as
"complete" until all actions have been completed successfully".)  If we
only allow a single selector, then we would have to issue multiple requests
to satisfy that case?  I think the list is an efficiency optimization.  I
don't know in practice how much someone might want to operate on multiple
selectors, but it seems like a reasonable thing to do.

  2) I agree that all trigger commands are mandatory, so there's no need
for an MtE flag.  If a selector is not supported by the dCDN it should just
put an error in the status saying so.

  3) StR was introduced to handle the blind relay of data in a tCDN.  I
think the real question is: should a tCDN propagate trigger commands that
it doesn't understand or not?  Given the trigger interface's ability to
propagate errors back up the CDN stack, I think it probably should just
forward requests.  As such, I don't think we need an StR flag; it would
just be true.

  4) I think I agree, but reserve the right to change my mind when I see
the updated text.  ;)

  5) GenericTriggerObjectsSelector is kind of long.  Maybe
GenericTriggerSpec?

  6) Perhaps: spec-type, selector-type, and selector-values?  Would
spec-type and/or selector-type have a registry for valid values?

thanx!

--  Kevin J. Ma

On Sun, Nov 14, 2021 at 2:45 PM Nir Sopher <[e-mail]> wrote:

> Hi All,
>
> Following the adoption of the RFC-8007bis draft, and the milestone set
> during the last IETF meeting, I would like to move forward and define the
> "Generic Trigger Object Selector" object.
>
> A quick recap:
> As defined in RFC8007, the trigger object holds a closed set of
> content/metadata selection properties:
>
>    - meta+data.urls
>    - metadata.patterns
>    - content.urls
>    - content.ccid
>    - content.patterns
>    - content.regexs
>    - content.playlists
>
> Being built of a closed set, whenever one would like to define a new way
> to select content, and therefore need to add a new such property, a new
> version of the trigger object has to be re-defined.
> In order to avoid such redefinition, we suggested defining the
> "GenericTriggerObjectSelector" object. The Trigger.v2 object would contain
> a list (?) of such objects and we will be able to continuously define new
> types of selectors without changing the Trigger.V2 object structure.
>
> Few questions comes to mind while trying to define the new Generic object:
>
> *1)* Would the Trigger.V2 object be holding a list of
> "GenericTriggerObjectsSelector"s or only a single one?
> Currently the Trigger object may hold a "metadata.urls" property as well a
> "content.urls" property etc..
> Citing RFC8007: At least one of "metadata.*" or "content.*" MUST be
> present and non-empty.
> However, what is the usecase requiring more than a single selection
> property to be used?
> And what is the semantics when using both "content.patterns" and
> "content.ccid" properties together? Is it an additive or a narrowing
> semantic?
>
> I would like to suggest that the Trigger.V2 object would hold a single
> "GenericTriggerObjectsSelector" object. It would be simple and clear.
> In the future, if one finds the need in creating an objects list, s/he can
> define a special GenericTriggerObjectsSelector type that is built of a list
> of other GenericTriggerObjectsSelector objects, and define its semantic as
> needed.
>
> *2)* Does the "GenericTriggerObjectsSelector" hold a
> "mandatory-to-enforce" (MtE) boolean property (similar to the
> GenericMetadata object)?
> As the newly defined object is used for target selection, and as I see it,
> without it the trigger is practically useless, I think the MtE property is
> not really needed. It's value should be "true" by convention.
> On the other hand, having this property anyway may be considered as a good
> practice.
>
> *3)* Does the "GenericTriggerObjectsSelector" hold a
> "safe-to-redistribute" (StR) boolean property (similar to the
> GenericMetadata object)?
> I believe it should.
>
> *4)* RFC8007bis already defines the GenericTriggerExtension object, which
> allows to define further instructions on the trigger execution (e.g. time
> of execution).
> Should the new GenericTirggerSelection object be merged with the
> GenericTriggerExtension?
> I believe that the 2 types of generic objects here have different nature
> of usage. One indicates "what to work on" and the other indicates "how to
> do the work".
> I would therefore suggest keeping them separated.
>
> *5)* What would be the real name of the new object?
> So far I called it "GenericTriggerObjectsSelector" but any suggestion
> would be highly appreciated.
>
> *6)* What would be the structure of the GenericTiggerObjectSelection
> object?
> Below is a suggestion of properties to start with.
> Note the separation to "selected-object-type" (content vs. metadata) and
> "selector-type" (url / patterns...)
>
>    - selected-object-type: metadata / content
>    - selector-type: url / pattern / regex / playlist / ccid
>    - selector-values: <a list of values in the proper type>
>    - safe-to-redistribute: True/False
>
>
> I would highly appreciate any input regarding the above discussion, so
> please share your thoughts,
>
> Nir
>
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni
>