RE: [kmip] First stab at a conformance profile

Dear TC,

I took a pass at trying to take the Proof-Of-Concept and represent it as a conformance profile. You should find this in the KMIP document repository as Conformance_Clause_Proposal_V3_POC_Profile_V1.pdf

I thought I'd be presenting a simpler profile than the POC profile, but before I propose a simpler profile, I'd like to see if it's even possible to take the conformance proposal as it currently stands and see how one would express the POC.

This way, people can see the conformance implications of something that's at least vaguely familiar before I venture into something more controversial.

Although you can read the document and see comments inserted at various spots, the summary is that I found I had several problems:
1) The difference between NOT SUPPORTED and OPTIONAL is vague, at least in my head. I seem to be doing a mental coin toss every time I try to decide which flavor of (!(REQUIRED)) I want. This may be a personal problem, or might be a conformance proposal problem. I think it's the latter (but that may be another symptom of my personal problem :-).

LarryH: I think it would be good to reword to avoid the use of the word "support". We should be able to use our existing key words to express expectations for compliance. I'm planning on sending Walt some reword of the conformance proposal to avoid that word altogether.

2) The conformance profile is still too coarse-grained. I think we need visibility into the enumerations on what types are supported by implementations. For example it's too coarse-grained to say I support Derive Key or I don't. I could have an implementation that supported only HASH-derived keys, and not the other types of key derivation. The conformance profile should allow this kind of expressiveness.

LarryH: Either we need to make the normative text be clear on which enumerated values MUST/SHALL be supported, etc. or we need to probably say something like "May be restricted/limited values" in the table and explain in the profile text for that profile. Seems like it might be easier to deal with it in the words for that profile, as someone mentioned on the call today.

3) I really don't understand the client conformance column. If the client doesn't make requests of particular types, then it is not going to have to handle the responses that deal with those particular types. It almost seems that the client column is a requester library and not an actor in the scenario.

LarryH: I think the client has to at least implement some function (must do something). Else, seems like most everything is optional in the client column. A possible exception may be when you hit things like "Protocol Version" in the template table.

Bruce A Rich
brich at-sign us dot ibm dot com

kmip message