Passing message-id to tailf:actionpoint callback

We have a requirement where we need to access the message-id of a NETCONF RPC request in the actionpoint callback that the application implements.

Could you please let us know if there is a way to pass the message-id of the RPC request to the actionpoint callback?

For example, if we assume the sample RPC request as below, we would like to pass “Reboot2” (message-id) to the callback.

<rpc message-id="Reboot2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

We want to store the message-id in the application which implements the actionpoint (action callback) and use the message-id to generate a few NETCONF notifications so that the northbound system can correlate the notifications to the RPC and take appropriate actions.

Please let us know if there is a way to achieve this. We want to avoid adding a custom message-id in the input of RPC, since there is already a message-id available.

I think you would be better off if you add a mandatory field to your actions - the netconf client is able to fill in the message ID, it should be able to fill in this field too. If this is not an option, the only way for you to be notified about netconf message IDs (at least I know of) is using ConfD notification API: you can subscribe to receive NETCONF event callback every time a NETCONF message arrives or is sent.

The callback for NETCONF events contains this data structure (in C):

struct confd_syslog_notification {
    int prio;   /* from syslog.h */
    int logno;  /* number from confd_logsyms.h */
    char msg[BUFSIZ];

You would be interested in messages with logno == 86 (86 is CONFD_NETCONF), msg might contain something like

id=14 got rpc: {urn:ietf:params:xml:ns:yang:1}action attrs: message-id="Reboot2"

and then another one

id=14 action name={''}actionname instance-identifier=/data/model/path, attrs: message-id="Reboot1"

As you can see, it contains quite useful data, but in completely unstructured form; you might also struggle a bit with synchronizing these callbacks with actual action callbacks. See more in man confd_lib_events / the user guide, and the misc/notifications example.

Note that NETCONF message ID is not a particularly good way of actually identifying messages, there is nothing that prevents the client from using the same message ID all the time, or even keeping it empty.