RE: [kmip-comment] Possible solution to referencing issues

[Eric Hibbard <Eric.Hibbard@hds.com>]

Mark,

 

Thanks for your quick reply. Also, please keep in mind that I’m a KMIP neophyte, but supportive.

 

Please see comments in-line.

 

-Eric

 

From: Mark Joseph [mailto:mark@p6r.com]
Sent: Monday, March 31, 2014 2:56 PM
To: Eric Hibbard; Patrick Durusau; Tim Hudson
Cc: kmip; tab@lists.oasis-open.org
Subject: Re: [kmip-comment] Possible solution to referencing issues

 

 

My second related beef, is that the text of the profiles should be the authoritative source for what compliance actually means (i.e., the normative text). If you have to look at the conformance test details, which in ISO would simply be "informative" text, you've potentially lost the battle to ensure interoperability  with KMIP.

Hi Eric, I want to make sure I understand what you are saying here.   The "conformance test details" you are referring to are the detailed test case documents?

 

EAH>> I was referring to materials like the Test Cases (Section 3) in “KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0” document. When one looks at this detail, there shouldn’t be any surprises (i.e., the normative descriptions should have it all spelled out in sufficient detail). After talking with Tim Hudson, it sounds like this may be the case with the new/updated v1.2 profiles.

 

 I have done a lot of work with IETF standards, for example the SSH RFCs.   I got to tell you they are terrible.   There are so many different interpretations that when I was building my company's version of an SSH server (from scratch) the only way I got it to work was to test it against the SSH server on linux.   There is no other way that would work.    I have also worked on several IETF email protocols and even though those specs are better the only way to get an implementation to work is again by testing it against many other implementations.   I have been doing this protocol development for too long.

 

EAH>> Superseded IETF RFCs can be an adventure; I spend too much time with things like TLS, IPsec, and Syslog. It may be worth noting that at the point where the KMIP TC wants to standardize a flavor of KMIP as an ISO/IEC document (definitely goodness), the version that gets submitted is likely to become the dominant version over time. I still believe that only the KMIP spec should be submitted (under PAS and OASIS does the maintenance) and the KMIP TC should continue to control the KMIP Profiles (and other documents).

 

What I really liked about KMIP was the conformance test details.   My company P6R ships a KMIP client.   And those conformance test details where extremely helpful in both building our client and testing with KMIP servers.   When there is a disagreement about what should go over the wire, as there always is, those detailed test details are the ultimate form of reference for both server and client.

I only wish that the SSH IETF documents had something similar.

 

EAH>> Interestingly enough, I ended up looking at the test details to try and figure out whether 3DES was mandatory to implement for KMIP clients. My earlier complaint was that an important detail like this should be explicitly stated in the profile description; it takes a fair amount of alcohol to get my brain to a mode where it can parse XML.

 

Best Regards,

Mark Joseph, PhD

President, P6R Inc.

mark@p6r.com