Re: [kmip] Groups - KMIP-ReKey-Examples-v1d.pdf uploaded

[Tim Hudson <tjh@cryptsoft.com>]

On 27/05/2013 2:28 PM, John Leiseboer wrote:

The proposal put forward by Bruce to narrow the scope of the Re-* operations to key value and lifecycle-related change seem reasonable to me. I think Bruce's suggested changes are sensible, consistent, a reasonable interpretation of intent, and will help with interoperability.

John - do you support Bruce's proposed changes (the various marked up word documents) as-is or not? That is the feedback that Bruce was seeking and the presentation we put together was to aid discussion on the topic to see if there was a reasonable level of interest in looking at this for KMIP 1.2 (with the assumption that there probably was not given no one had indicated support so far).

If consensus is that this is too much change for v1.2, then I would propose that text be added somewhere (main specification? User Guide?) to warn implementers of a possible future change.

That would not be a sensible approach to take IMHO - warning in a document about a change which the group as a whole has not indicated support for so far.

The nature of the change Bruce is suggesting is to make it clear that the current behaviour (analogous to Create) remains entirely allowed and there is a recommendation to limit to changing just a few "special" attributes noted. This will do absolutely nothing for interoperability other than to clearly document two very different (and incompatible) views as both being acceptable leaving clients to not know which view a server supports. Bruce was very clear that he marked it SHOULD rather than SHALL in order to try to make it more acceptable to the group for inclusion within KMIP 1.2 by being able to state that all existing behaviours remain supported - but that approach does not help interoperability at all.

Both Judy and I have expressed our contrary views to making this change on the list (and in the call last week).

More test cases will be added (a work in progress) to cover as many of the areas we have been discussing as possible.
That will at least address the issue of leaving items open to change absent test cases demonstrating use of functionality.

Tim.