[i2rs] Comments on draft-clarke-i2rs-traceability-03

[Ignas Bagdonas <[e-mail]>]

Dear authors,

Some assorted comments on draft-clarke-i2rs-traceability-03.


NULL string value may be a valid parameter or return value and that 
should be differentiated from no value present at all.

Asynchronous, long running, blocking operations. Client request may not 
always be processed synchronously or within a bounded amount of time. To 
keep Operation and Result Code values in the same record may require 
buffering the trace log entries, and that may result in additional 
resource load on the agent and network element.

Blocking on traceability information export. Traceability information 
export is a valuable diagnostics tool, but that is not the main function 
of the I2RS agent, and network element as such. Possible blocking of 
traceability component should not block the operation of the agent.

Temporary on-element traceability data storage requirements. Related to 
the blocking point above and depending on many implementation aspects it 
may be more practical to store the traceability data and export/buffer 
it periodically than to do it synchronously with the requests. In such 
case the amount of resources required for such temporary storage must 
not interfere with normal operation of the agent itself.

Intermixed operations. I2RS agent may respond to incoming requests 
non-sequentially, different operations may take different amount of time 
required for completion. Batching of traceability data export would need 
to account for a possibility of signaled operation still being processed 
at the time of export.

Timestamp granularity. RFC3339 defines subsecond granularity in 
timestamps but leaves the granularity of it aside. While this is highly 
implementation dependent, the nature of multiple and rapid operations 
would tend to ask for a recommended minimum granularity of trace records 
to be specified. While not enforcing, it could be recommended to support 
UNIX style 32.32 bit second.microsecond or 64 bit nanosecond timestamp 
granularity represented in RFC3339 format.

Section 7.1 - transactions. The term 'transaction' in this paragraph 
seems to describe the internal machinery of the agent that will likely 
be dependent on many implementation factors and possibly not having much 
meaning outside the context of such implementation if exported via the 
traceability mechanism. The I2RS operation level transactions typically 
would be controlled by the Actor and/or Client, and would not be visible 
to the Agent. Could you clarify the meaning of the transaction term as 
used in this context?

More-trace-logs-follow marker. An operation may return in multiple 
(sub-)results, possibly spread over a longer period of time compared to 
request processing and initial trace entry generation. A mechanism for 
recording into trace log that more output will follow at some later time 
would be useful.

Request/response traceability split, sub-response identifiers. A single 
request operation may result in more than one actual operation performed 
and more than one response being returned. Supporting such trace records 
would need to have a request and response correlation identifiers and 
ability to identify multiple responses.


Ignas