A few remarks below,
Larry H
Emulex
From: Bruce Rich [mailto:]
Sent: Thursday, July 23, 2009 8:24 AM
To:
Subject: [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
