Re: [kmip] Groups - kmip-https-profile-v1.0-wd04.pdf uploaded

[Tim Hudson <tjh@cryptsoft.com>]

JohnL (and others), the context of the discussion to date is pretty simple.

1) a vendor can elect to not be conform with a profile (or the 
specification)
2) a vendor can elect to pick any port they like for offering KMIP (TTLV)
3) a vendor can elect to pick any port they like for offering KMIP 
(HTTPS-TTLV)
4) if a vendor elects to use the IANA registered port (5696) for 
offering KMIP services then in order to conform with this profile they 
must support the protocol registered with IANA for that port as well

It is that simple. No vendor is forced to use port 5696 (consistent with 
the base specification).

Based on many discussions to date the consensus as I understand it is 
that the base specification should have also included this text and we 
will be proposing that additional text be included in KMIP 1.2.

The concept that the KMIP TC would consider use of a port we registered 
for a specific protocol (KMIP-TTLV) that was registered with IANA be 
acceptable for using for another protocol (KMIP-HTTPS-TTLV) is not a 
position that is reasonable or supportable to take as a technical 
committee in my opinion (which I know is shared by others).

KMIP is focused on interoperability and the choices which have guided 
the TC to date have to been to err on the side of choices which 
encourage realisation of that interoperability for the ultimate end 
users of the specification.

The discussions on the original HTTPS profile and on the IANA port 
registration I know predate some participants and these issues have been 
discussed again. We cannot always reach consensus on a topic and that is 
why we have a voting mechanism in place.

The concept of supporting a HTTPS based protocol goes back to the 
original precursor of KMIP (2007) and vendors have released product 
which supports this profile. The lack of progress on getting this 
documented and recognised by the KMIP TC is something we all need to 
stop and reflect on.

We also have the broader issue of handling profiles (the library of 
profiles discussed by  Bob Griffin over the last three months) and the 
guidance for those profiles too will be that they should not take a 
position which conflicts with the interoperability objective of the work 
of the technical committee.

We need to see more profiles documented and published along with their 
self-contained test cases and a formal independent conformance testing 
program in order to actually deliver interoperable products.

How these profiles connect into KMIP and become recognised in that 
context is a remaining problem to tackle - and it is not a simple one 
and not one which we can address only in the context of KMIP 1.2 - as 
many profiles are going to be equally relevant to KMIP 1.0, KMIP 1.1, 
and KMIP 1.x/2.x, etc. It is that discussion which I think remains to be 
addressed.

Tim.