Re: [kmip-interop-tech] KMIP interop POC, next steps

> On last week's interop-call, the people present (John and Stan of HP, Alan and
> Paul of SafeNet and myself) discussed how to proceed with the proof-of-concept
> interop calls and the interop-effort in general. We agreed that in light of the
> current lack of interop-activity, it would make sense to take a "summer
> vacation" from the interop-calls, and resume at a later date when there is more
> to test.

I (incorrectly) assumed the call wasn't on given that Bob canceled the main call
and the previous weeks call was somewhat short or I would have joined the call.
> I propose to cancel this Thursday's interop call and bring the definition of new
> use cases up as an agenda item on the TC call with the larger group.
I agree with the approach. Although the wider group seems to be somewhat less
enthusiastic about practical implementation issues.

I'd like to canvas opinions on the topic of adding additional simple use cases
or changing the current use cases to allow for testing of each 'feature'
independent of the rest of the logic. The current use cases have a mix of
features in them and I found during implementation that more ancillary stuff had
to be implemented for certain use cases.

e.g. 3.1.4 required GetAttributeList, AddAttribute, ModifyAttribute, and
DeleteAttribute to be implemented in a use case focused on Dual Client use and
4.1 Revoke also has AddAttribute, ModifyAttribute, and DeleteAttribute.

I do understand that the use cases are not intended to be a set of unit tests,
however we all seem to be using them to test incremental implementations and are
hitting blocks of functionality intermixed.

I've also been testing outside the use case context so turning those tests into
use cases would be straight forward to do.

Tim.