OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


As an interested outsider, I would strongly encourage you to adopt a model that either   1) new versions supersede older versions and there's no illusion that old versions are relevant to new versions (basically what the IETF does), or 2) every document is sufficiently complete in that it is easy for one to see what it is relevant to (i.e., if you have to be active in the KMIP TC to get some core concept/detail, you have failed). I personally prefer the former because I'm a standards person, and if you ever intend to submit the KMIP spec to ISO/IEC JTC 1 you will be forced to pick a single version of the document (not 3 like now).

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. 

The current situation has sufficiently spooked the editor of ISO/IEC DIS 27040 (Information technology - Security techniques - Storage security) that the KMIP language in the DIS text that encouraged the use of specific profiles is being dialed back to something more generic.

-Eric

Eric A. Hibbard, CISSP, CISA, ISSAP, ISSMP, ISSEP
CTO Security and Privacy

International Representative, INCITS TC CS1 Cyber Security
Co-Chair, Cloud Security Alliance (CSA) - International Standardization Council (ISC)
Co-Chair, American Bar Association - SciTech Law - eDiscovery & Digital Evidence Committee
Vice Chair, American Bar Association - SciTech Law - Cloud Computing Committee
Chair, IEEE Information Assurance Standards Committee (IASC)
Chair, SNIA Security Technical Work Group
Vice Chair, IEEE Security in Storage Work Group (P1619)
 
HITACHI DATA SYSTEMS
2825 Lafayette Street
Santa Clara, CA 95050-2639
P 408.970.7979/ C 408.314.0515
eric.hibbard@hds.com 



-----Original Message-----
From: Patrick Durusau [mailto:patrick@durusau.net] 
Sent: Saturday, March 29, 2014 4:24 PM
To: Tim Hudson
Cc: kmip; tab@lists.oasis-open.org
Subject: Re: [kmip-comment] Possible solution to referencing issues

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim,

But the problem isn't that every profile must cover all three versions of the specification. That would be bad enough.

Given the profile documents for each specification, every profile must treat all 6 specifications and profiles. (As they attempt to do and fail currently.)

Given 9 profiles, that 54 total references across 6 specifications and profiles.

And every new profile will add another 6 mappings. I am sure as time goes by the TC will want to create more profiles and perhaps later versions of the specs + profiles.

Unless the TC addresses this issue now, with something more than it has considered the problem and is going forward as is, the situation is going to get worse, far worse.

The reliance on "work flows" to avoid specifying behaviour in prose signals that no one can specify the "work flow," you can only specify some subset of values and then the protocol "should work like this."

Standards are not made out of subsets of allowed values. Standards specify ranges of values to which any implementation can conform.

Hope you are having a great weekend!

Patrick


On 03/29/2014 06:39 PM, Tim Hudson wrote:
> On 30/03/2014 1:47 AM, Patrick Durusau wrote:
>> First, let me confirm that KMIP-Spec 1.2 is a superset of KMIP-spec 
>> 1.1 and KMIP-spec 1.0.
> 
> There are behaviours within KMIP-Spec 1.2 that are not compatible with 
> KMIP-Spec 1.1 and KMIP-Spec 1.0 and they have to be referred to 
> separately and each version of the specification documents a 
> particular major.minor version of the protocol. Make it clearer - 
> KMIP-Spec 1.2 does not document KMIP protocol version 1.0 or protocol 
> version 1.1. Each specification is independent of the other 
> specifications and the profiles have to cover all three versions of 
> the specification.
> 
> The test cases document the normative conformance message flows and 
> values and the allowed variations document where an implementation is 
> permitted to vary the details form the normative message flows - that 
> is their point and function. The profiles document a set of messages 
> that represent the minimal message flows required for conformance to a 
> given profile.
> 
> As a technical committee we explored a number of different approaches 
> for handling cross-version references and for handling documented 
> conformance requirements and the approach we have in the profile 
> documents represents the one which allows specification of conformance 
> sufficiently precisely to meet the interoperability objective.
> 
> Thanks, Tim.
> 

- --
Patrick Durusau
patrick@durusau.net
Technical Advisory Board, OASIS (TAB)
Co-Chair, OpenDocument Format TC (OASIS) Editor, OpenDocument Format TC, Project Editor ISO/IEC 26300 Former Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Co-Editor, ISO 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTN1XyAAoJEAudyeI2QFGoEvAQAPCSqdI6xrSdSma0YM8/Plm5
w9m6WEDzCX6fQp1NtLcn3p6GcZsZhlKp1KqmEbtBQc3eK1eACUaMy0US8svI0/Wr
mGzfMdhbfAxRW1N87HTYbb/1qGAi4imFqHia76Kb6jmUlQqagHk6Zjajbh/CtKoP
HobLqzttHF+nVg9xByae9HjebUfmjhEdS8hKxro2frFUqa3k0kNI0+45x380RXmW
2R5F8omwC1jiFcXpuB+WSeW8SSfK/ChZ5W0d2ji5zClhhyVOOezEFarREBqxDi4b
Py3eqdsLo+HuGRCQNwOzQULMLZNzEiP4mjbAMiLog7OtM+Nn9bOqxVbhpkIuRODd
Pw88ArOVom/pxICjT5b1bIUr40N+fCrXwRc9Y834gyT4Ja0lGpCmYfUWZrBP3z8C
7J0ft/ktqgxQ1CiMD4V1N2WR0+ECzvlzRHKR1ywvtSKwerD0JKdAVTSCPM9dKVIP
1rkGAo0OHrISA23aub/BQG0X4ROZ7cu585bfA/HynPvlw116snJVWZzoDNTOUxVz
L3Qhf7ZD1IL6KxQStEfeXmPgnhjCXD8yOmO5pvPUzIpS2QCaAaMUb1gUrspkpBzE
eLHl40x3TP9GUJR3SQMfxMXH6VU4JPuiJRn2Ip1Qp1C5PFKGR3K/6bI/YuU87L+L
XUlmgwMdhgn8d8wzgRHv
=Ldr2
-----END PGP SIGNATURE-----

--
This publicly archived list offers a means to provide input to the OASIS Key Management Interoperability Protocol (KMIP) TC.

In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting.

Subscribe: kmip-comment-subscribe@lists.oasis-open.org
Unsubscribe: kmip-comment-unsubscribe@lists.oasis-open.org
List help: kmip-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/kmip-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip
Join OASIS: http://www.oasis-open.org/join/



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]