Re: [kmip] Groups - Client / Server Correlation Value uploaded

[Tim Hudson <tjh@cryptsoft.com>]

On 16/12/2015 12:35 PM, Featherstone, David wrote:
>
> Hi Anthony
>
>  
>
> I support effective logging, but the existing protocol specification
> provides all that is needed in the form of the *Unique Batch Item ID*.
> This field supports the unique identification of each and every *Batch
> Item* originated by a client *_or_* by a server:
>

Unfortunately it doesn't allow for request level tracking or flows that
span multiple requests and its use is entirely optional (for requests or
responses containing a single batch) and it doesn't handle error
responses where you may have no response for a given input batch item in
a prior request.

Basically for the logging context for flows we have nothing currently
other than vendor-specific extensions.

There is also no expectation of the unique batch item id being anything
actually particularly unique cross-request - noting that most of the
examples use 01 02 03 etc as a naming scheme - nothing of course
precludes a vendor from implementing the unique batch item id as a
globally unique item cross-requests but we haven't seen any vendor to
date taking that as a strategy so it doesn't offer a solution to the
stated problem.

The purpose of the unique batch item id was to handle out-of-order batch
item processing - it is not intended to be a globally unique item
(although it isn't precluded from being one either).

We have talked numerous times during plugfests and interops for wanting
to have a way to line up the client and server logs for faster (and more
automated) matching of checking of conforming results and this
definitely addresses that concern whereas at the batch item level it
would not.

Tim.