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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
