Feedback on reviewing wd02.
"The internal implementation of this feature at the server end is a matter of choice for the vendor: storing multiple key blocks with all necessary combinations of attributes or generating key blocks dynamically are both acceptable approaches."
I'm trying to follow what this is suggesting as an alternative. I don't.
I think we could just remove the two paragraphs at the end of 3.10 and avoid the issue because they aren't actually clear in what they are trying to achieve other than providing support for different server vendors to debate the merit of different approaches. We have taken an approach of remaining silent on that topic to date.Â
Section 3.15
There seems to be a lot of repetition of details from the specification and checking between the spec and the usage guide for consistencyÂ
"This is intended primarily for clients that were disconnected from the server at the time that the client performed that operation on a given key."
I don't see it that way.
"KMIP allows the specification of attributes on a per-client basis, such that a server could maintain or present different sets of attributes for different clients. This flexibility may be necessary in some cases, such as when a server maintains the availability of a given key for some clients, even after that same key is moved to an inactive state (e.g., Deactivated state) for other clients. However, such an approach might result in significant inconsistencies regarding the object state from the point of view of all participating clients and should, therefore, be avoided. A server should maintain a consistent state for each object, across all clients that have or are able to request that object."
This conflicts with the specification which states in Section 4 - "When attributes are returned by the server (e.g., via a Get Attributes operation), the attribute value returned SHALL NOT differ for different clients unless specifically noted against each attribute."
IMHO the solution is to remove that paragraph.
Section 3.20
"In KMIP 1.x, it was expected that the client must supply these parameters, but KMIP 2.x allows ..."
Section 3.40Â
"The operation was added to KMIP 1.1. KMIP 1.0 clients and servers may therefore not support this operation. If the Discover Versions request is sent to a KMIP 1.0 server and the server does not support the operation, the server returns the âOperation Not Supportedâ error."
We shouldn't refer to KMIP 1.x at all in this KMIP 2.x document. Those should be adjusted to remove all reference to 1.0 or any discussion of the differences.
Section 3.53
"In KMIP 2.x additional " ... we should remove the reference to KMIP 2.x and just note what is present. We aren't comparing versions in this document.
And finally, Tony included the participant list in his recent spec upload - copying that in now would be appropriate.
Tim.