mgmtCmd EXECUTE response?

[Spongman]

in TS-0001 Table 10.2.8.18-1: <mgmtCmd> EXECUTE it says "It shall also provide in the response the URL of the created resource"

• what is the mechanism for this?
• presumably this can be multiple if a <group> is specified?

[ankraft]

I thing the full text reads

It shall also provide in the response the URL of the created \<execInstance> resource.

This is similar to other async or non-blocking requests: The CSE creates a resource that holds the original request, has the state of the request and will later also hold the response of it. The request originator needs to know the URI of the created instance in order to check its status and retrieve a response later. That is this URI.

presumably this can be multiple if a is specified?

No, I don't think that <group> is involved here. And even if it would be, then the response to a <group>/fopt would be a single aggregated response.

[Spongman]

but this is not in response to a CREATE request, it's an UPDATE on the mgmtCmd's execEnable:

The Execute procedure shall be used by an Originator in order to trigger execution of a specific management command on a managed entity, by employing an UPDATE method to the execEnable attribute of an existing resource on the Hosting CSE.

also, wrt. groups:

if the execTarget attribute of the addressed addresses a group, the Hosting CSE shall create corresponding resources for each target in the group and provide the corresponding URLs in the response

8.1.3 specifies the form of the response to an UPDATE request. where are these new execTarget URLs suppsoed to go?

[ankraft]

You are right. I remembered a different procedure.

In TS-0004, clause 7.4.16.2.3.2 Update (Execute), the procedure is explained in detail. Step 3:

3. The Receiver shall copy the following attributes from to each created: execMode, execFrequency, execDelay, execNumber, and execReqArgs. The execStatus of is set to INITIATED. The Receiver shall set the execTarget attribute of each sub-resource to the URI of each target resource.

[Spongman]

sure, but those copied attributes are placed in the new execTarget resource. the response to the UPDATE request, however, only contains attributes of the resource being updated - the mgmtCmd. again: where are the URLs of the new execTarget resources returned?

[Spongman]

also, how does one EXECUTE a single mgmtCmd at two different times to two different targets? is it possible to perform two different UPDATE requests that each update both the execTarget AND execEnable attributes simultaneously?

[ankraft]

sure, but those copied attributes are placed in the new execTarget resource. the response to the UPDATE request, however, only contains attributes of the resource being updated - the mgmtCmd. again: where are the URLs of the new execTarget resources returned?

I have to say that this seems to be missing for now. One can do a DISCOVERY request to find the <execInstance> resource, but this is not convenient at all. I agree, there should be a RO attribute that is a list of all the <execInstance> resources for a particular UPDATE (execution) request.

[ankraft]

also, how does one EXECUTE a single mgmtCmd at two different times to two different targets? is it possible to perform two different UPDATE requests that each update both the execTarget AND execEnable attributes simultaneously?

I think this should be possible. A new EXECUTE should create new <execInstance> resources for that request.

[Spongman]

yeah, doing a DISCOVERY to find out which execInstance was the one created by the previous UPDATE is obviously prone to sequencing errors if there are multiple simultaneous UPDATE calls in-flight.