Re: [CDNi] CI/T Triggers Interface - The Command

[Kevin Ma <[e-mail]>]

Hi All,

  (As an individual) Comments on -09 below.  It's mostly nits, but there
are a few questions as well.

thanx!

--  Kevin J. Ma

general:
  "e.g. " -> "e.g., "
  "i.e. " -> "i.e., "
  "canceled" -> "cancelled"

section 1:
  "objects comes to replace" -> "objects replace"
  "allows the better monitoring of triggers execution via the functionality
of error propagation on cascaded CDNs" -> "includes cascaded CDN error
propagation for improved trigger execution monitoring."

section 2:
  "uCDN, or" -> "uCDN or"
  "version. I.e.," -> "version, i.e.,"

section 2.1:
  "count on that" -> "rely on that"
  "can choose" -> "MAY choose"

section 2.2.1:
  "which uCDN it acquired content from" -> "from which uCDN it acquired
content"
  "HTTP 403" -> "responding with an HTTP 403"

section 3.1:
  "describe trigger action" -> "describe trigger actions"
  perhaps a reference to 6.2.6.1 for "eunsupported"

section 3.2:
  "the trigger is applied on" -> "upon which the trigger is applied"
  "individual CDNI trigger spec" -> "individual CDNI trigger specs"
  perhaps a reference to 6.2.6.1 for "espec"
  a reference to what regex standard for "url-regex-match"

section 3.2.1:
  "also specify" -> "also specifies"
  "to be matched with" -> "against which to match"
  perhaps a reference to 6.2.6.1 for "esubject"

section 3.3:
  "In this 2nd edition we define" -> "This 2nd edition defines"
  "for the trigger to be executed" -> "in which to execute the trigger"

section 4:
  "objects versions. I.e. a subsequent call" -> "object versions, i.e.,
subsequent calls"
  "dCDN, and have not" -> "dCDN and have not"
  "uCDN, or expired" -> "uCDN or expired"

section 5:
  "trigger activity" -> "trigger an activity" or "trigger activities"

section 5.2:
  "for change" -> "for changes"
  "does not exists" -> "does not exist"

section 5.4:
  "time, using" -> "time using"
  "to delete a trigger only in a terminal status, and use" -> "to only
delete terminal triggers and use"
  "It is\n\nRECOMMENDED" -> "It is RECOMMENDED"

section 5.7.1:
  "traceback an error to" -> "trace an error back to"
  "to dCDN-C and errors" -> "to dCDN-C, and errors"
  "trigger, to be able" -> "trigger, be able"
  remove "and depending on the implementation,"
  "relates to" -> "relates"
  step 7 should note that dCDN-B is also acting on it's own command in 7.1,
and dCDN-C's action is 7.2 in the diagram.

section 6:
  "6.1.4" -> "6,1,4, respectively"

section 6.1.1:
  "to act upon" -> "upon which to act"

section 6.1.3:
  this says "errors" is optional, but section 3.1, 3.2, and 3.2.1 have
MUSTs for specifying an error?  "errors" should at least be mandatory in
those cases?
  there should be individual descriptions for coll-all, coll-pending,
coll-active, coll-complete, and coll-failed
  "cdi-id" is inconsistent with "cdn" in 6.2.5

section 6.2:
  "6.1, and" -> "6.1 and"

section 6.2.5:
  "based on from the" -> "from the"
  "A Trigger Specification" -> "Array of Trigger Specifications"
  "Missing property" -> "Property omission"
  "Yes. In the case the dCDN does not like to expose this information, it
should provide its own CDN PID." -- not sure what this means?  is this
trying to say that if the dCDN doesn't want to expose the pids of its
dCDNs, it can use its own PID?

section 6.2.6:
  i question whether the paragraph about status reason is necessary here

section 6.2.6.1:
  i question why this is a subsection of 6.2.6 and not just 6.2.7
  "interface, utilizing" -> "interface using"
  "preferable method" -> "preferred method"
  "capabilities, is" -> "capabilities is"

section 6.2.2:
  "6.2.1 includes" -> "6.2.1, includes"
  "for dCDN when" -> "for dCDNs when" or "for the dCDN when"
  "for example content" -> "for example, content"

section 6.2.2.1:
  "Trigger spec in" -> "Trigger specs in"

section 6.2.3:
  "for dCDN when" -> "for dCDNs when" or "for the dCDN when"
  "it is thus the responsibility of the extension specification to define a
consistent default behavior for the case the extension is not present" --
this is confusing.  if the extension is not present, it may be the case
that the uCDN is unaware of the extensions existence, in which case the
default would have not bearing on the request, so what good is a default
behavior for an unknown extension.

section 7.2:
  "the trigger applies to" -> "to which the trigger applies"
  "content, as" -> "content as"
  "for content spec subject" -> "for the content spec subject" -- perhaps
also a ref to 3.2.1

section 7.4.1:
  for URI signing, there was a POSIX vs PCRE debate, and POSIX won.  should
the same apply here?  see:
https://mailarchive.ietf.org/arch/msg/cdni/_0Y6yyc4IjIY4cB5vunCbSA2ar0/ and
https://datatracker.ietf.org/doc/html/rfc9246#name-uri-regular-expression-cont

section 7.5:
  "content spec subject" -- perhaps a ref to 3.2.1
  "protocol to be when" -> "protocol to used be when" -- does this need to
be explicit?  can it not be inferred from either the file extension, mime
type, or file header?

section 8.2:
  "in a specific schedule" -> "on a specific schedule"
  "wish to to" -> "wish to"

section 8.2.1:
  in the json examples: the datatimes should have double quotes and there's
an extra comma after the end datatime

section 8.2.2:
  in the json examples: the datatimes should have double quotes and there's
an extra comma after the end datatime

section 8.2.3:
  seems like a lot of effort just to get a datetime with no timezone.  can
we not just use ISO8601 localtime?
https://en.wikipedia.org/wiki/ISO_8601#Local_time_(unqualified)

section 9:
  "extensions and properties" -> "extensions, and properties"
  "policies and so on" -> "policies, and so on"


On Sun, Jul 30, 2023 at 11:44 AM Nir Sopher <[e-mail]> wrote:

> Hi All,
>
> To summarize, we would like to propose the following (already integrated
> into v08).
>
> The ci-trigger-command.v2 object is splitted into 2 objects
>
>    - ci-trigger-command.trigger.v2 - for trigger creation - to be posted
>    on the "collection" path
>    - ci-trigger-command.cancel - for trigger cancellation - to be posted
>    on the "trigger status resource" path
>
> We prefer the cancellation command to be posted on the specific resource
> path, and not support bulk operations as
>
>    1. It is more standard - make the operation on the actual resource and
>    not on the collection
>    2. Bulk operations add complexity to the API. E.g. what should be
>    returned from a cancel command in which only part of the target triggers
>    were identified? Or maybe when the command succeeded only for part of the
>    specified triggers?
>    3. We did not find real added value in bulk operations - supporting
>    bulk operations just seems to move the complexity of monitoring several
>    triggers cancellation from the uCDN to the dCDN
>
> We further considered changing the specification of the "DELETE" command
> so it would be more http standard. I.e. deletion would fail on triggers
> with execution which are in progress (not in
> "canceled"/"failed"/"succeeded" status). If an uCDN wants to cancel and
> delete a trigger it should first cancel it, monitor its status and whether
> it was really canceled, and only then delete it.
> *We decided not to make such a change* as this change is a protocol
> change which is not backward compatible. Note that a careful uCDN can just
> adopt to the methodology of "cancelling -> monitoring -> deleting" flow. We
> will add this as a comment to the draft.
>
> Best Regards,
> Sanjay&Nir
>
> On Fri, Jul 14, 2023 at 5:50 PM Nir Sopher <[e-mail]> wrote:
>
>> Thank you Kevin for bringing up these points:)
>> See response inline.
>> Cheers,
>> Nir
>>
>>
>> On Fri, Jul 14, 2023, 07:14 Kevin Ma <[e-mail]> wrote:
>>
>>> Hi Nir,
>>>
>>> > Can anybody provide the incentive of defining a command object that
>>> augments the 2 different commands?
>>>
>>> I think your guess is correct, that it felt "simpler" at the time to
>>> just define one message and one payload type.
>>>
>>
>> [NS] ack. Thanks
>>
>>>
>>> > why did the authors prefered to cancel a trigger via a "command" sent
>>> on the collection resource path, and not a command sent on the already
>>> created trigger resource.
>>>
>>> I think the interface supports both?  the delete command can be sent to
>>> the resource where the "effect is similar to cancellation".  I think the
>>> cancel is a bulk cancel, and the delete is the individual cancel?
>>>
>>
>> [NS] I believe the "delete" command cannot replace entirely the "cancel"
>> command as the deletion does much more than canceling. After the deletion,
>> the trigger can no longer be monitored as its status resource does not
>> exist anymore - the uCDN cannot even know whether the trigger was executed
>> or not. So a designated "cancel" command is essential.
>>
>> Thinking it further, I believe that the definition of the "DELETE"
>> action, as including a cancellation, is not a standard one. A standard API
>> would probably allow "DELETE" to be called only on resources in a terminal
>> state (failed/succeed/cancel triggers) and fail with some 4xx otherwise.
>> With such an API, the uCDN would have to first "cancel" the trigger,
>> monitor it, and then, when the trigger reaches the "canceled" status,
>> delete it. This is probably an added complexity for the uCDN, but this is a
>> zero sum game - either the uCDN or the dCDN would carry the complexity.
>>
>> Wrt individual "cancel" command vs. a bulk one. My guts feeling aim to
>> the individual trigger cancel command. Creation and deletion are done on a
>> single trigger basis, and I'm not sure whether there is an added value
>> specifically in bulk deletion. Especially as the input for the cancel
>> command is the resource path, with no patterns or something like that to
>> make the uCDN life significantly easier.
>> Furthermore, bulk operation adds unnecessary complexity to the API and to
>> the dCDN side implementation. For example, what should be the response for
>> a cancel command where one of the resources does not exist? Should the
>> entire command fail or part of the trigger should be cancelled?
>>
>>>
>>> > the cdn-path property ... really needed to be included in a "cancel"
>>> command?
>>>
>>> the cdn-path is a loop detection mechanism.  I think it applies equally
>>> to cancel commands, if they are forwarded to further downstream CDNs.
>>> Whether that is likely or not can be argued, but I think the functionality
>>> still applies?
>>>
>>
>> [NS] Im not sure regarding loop detection in trigger cancellation. As I
>> see it, as cancellation is done based on the triger resource path, and not
>> by trigger description, we know that the to be canceled trigger exists and
>> valid, and that loop detection was already made during its creation. The
>> dCDN just needs to verify that the uCDN sending the cancellation command is
>> the owner/has authorization to delete the trigger. Furthermore, if deletion
>> does not check the cdn path, why should cancellation
>>
>>
>>
>>> thanx.
>>>
>>> --  Kevin J. Ma
>>>
>>>
>>> On Tue, Jul 4, 2023 at 4:38 PM Nir Sopher <[e-mail]> wrote:
>>>
>>>> Hi,
>>>>
>>>> As you may know, we are working on preparing the "Control Interface
>>>> Triggers 2nd Edition" draft
>>>> <https://datatracker.ietf.org/doc/draft-ietf-cdni-ci-triggers-rfc8007bis/> -
>>>> preparing it for WG last call. Depreacating RFC 8007.
>>>>
>>>> During the last reviews - preparing the new draft version, we started
>>>> to wonder wrt the dual usage if the "ci-trigger-command" object /MIME type
>>>> - for both POSTing a trigger and canceling it.
>>>>
>>>> The object is built of the following properties:
>>>> 1. Trigger: a trigger specification object
>>>> 2. Cancel: URLs of existing trigger statues to be canceled
>>>> 3. cdn-path: a list if CDN pids, listing the trigger propagation path
>>>>
>>>> The "Trigger" and "Cancel" properties, are practically indirectly used
>>>> to distinguish which is the command to be executed - create a new trigger
>>>> or cancel others. Exactly one should be populated.
>>>>
>>>> Can anybody provide the incentive of defining a command object that
>>>> augments the 2 different commands? Wasn't it more strait forward to define
>>>> 2 separate objects, one for the trigger creation and one for cancelation?
>>>>
>>>> My best guess is that as these commands are both "POST"ed  to the same
>>>> resource path, the authors preferred to have a single object and MIME type
>>>> for both.
>>>>
>>>> A further question is why did the authors preferred to cancel a trigger
>>>> via a "command" sent on the collection resource path, and not a command
>>>> sent on the already created trigger resource. The object is ready and can
>>>> be managed.
>>>>
>>>> And the last question relates to the cdn-path property. This property
>>>> is mandatory, but it really needed to be included in a "cancel" command?
>>>> How should the dCDN refer to it when canceling a trigger?
>>>>
>>>> Cheers,
>>>> Nir
>>>>
>>>> _______________________________________________
>>>> CDNi mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/cdni
>>>>
>>>