OASIS Technical Committees Issue Tracker | |||||||||
Displaying 7 issues at 15/Jun/16 6:49 PM. |
Issue Type | Key | Summary | Description | Priority | Reporter | Affects Version/s | Proposal | Environment | Created |
---|---|---|---|---|---|---|---|---|---|
Bug | TAB-1407 | Conflicting Conformance Clause Definitions |
Sections 6.9 and 6.10 present conflicting conformance requirements for XML Client v1.3 Profile Conformance:
***** 6.9 XML Client KMIP v1.3 Profile Conformance KMIP client implementations conformant to this profile: SHALL support [KMIP-SPEC] SHALL support the Basic Authentication Suite conditions (3.1) and; SHALL support the XML Client conditions (5.4.2) and; SHALL support one or more of the XML Mandatory Test Cases KMIP v1.3 (5.4.4). 6.10 XML Client KMIP v1.3 Profile Conformance KMIP client implementations conformant to this profile: SHALL support [KMIP-SPEC] SHALL support the Basic Authentication Suite conditions (3.1) and; SHALL support the XML Server conditions (5.4.3) and; SHALL support mapping to/from XML of all TTLV tags and enumerations specified within [KMIP-SPEC] and; SHALL support all of the XML Mandatory Test Cases KMIP v1.3 (5.4.4). ***** One definition has four requirements and the other had five. Another varying set of definitions, see: 6.13 compare 6.14 - different requirements for Symmetric Key Lifecycle Server KMIP v1.3 Profile Conformance Same for 6.27 and 6.28 Same for 6.29 and 6.30 Same for 6.33, 6.34 Same for 6.35, 6.36 |
Blocker | Patrick Durusau | Key Management Interoperability Protocol Profiles Version 1.3 | Conformance targets require *unique* names to avoid confusion as to their requirements. Proof your conformance clauses carefully after re-casting. | Conformance | 15/Jun/16 6:48 PM |
Bug | TAB-1406 | Section 5 - Conformance clause? |
Is Section 5 also a conformance clause? I ask because it has as more detail than the reported conformance clause 6.
Why have duplicate conformance clauses? |
Critical | Patrick Durusau | Key Management Interoperability Protocol Profiles Version 1.3 | Suggest one conformance clause is more than enough. More than one leads to confusion. | Conformance | 15/Jun/16 6:40 PM |
Bug | TAB-1405 | Possible examples? Non-Normative? |
5.4.1.6.2 Structure reads:
5.4.1.6.2 Structure ***** For XML, sub-items are nested elements. <ProtocolVersion type="Structure"> <ProtocolVersionMajor type="Integer" value="1"/> <ProtocolVersionMinor type="Integer" value="0"/> </ProtocolVersion> <ProtocolVersion> <ProtocolVersionMajor type="Integer" value="1"/> <ProtocolVersionMinor type="Integer" value="0"/> </ProtocolVersion> ***** For this, other XML and JSON content, are these non-normative examples? None of them are labeled, numbered or otherwise presented as examples. |
Critical | Patrick Durusau | Key Management Interoperability Protocol Profiles Version 1.3 | Label and number all the examples, if that is indeed what they are. | Normative | 15/Jun/16 6:39 PM |
Bug | TAB-1404 | Conformance Test Cases? |
I am assuming that section 4 Conformance Test Cases has some relationship to later:
5.6.4.1 SKLC-O-1-13 See test-cases/kmip-v1.3/optional/SKLC-O-1-13.xml But that is far from clear. Moreover, by placing the test cases outside of the document in machine readable format, it controls in case of conflict with the prose, if that was your intent. |
Critical | Patrick Durusau | Key Management Interoperability Protocol Profiles Version 1.3 | Clarify the relationship between section 4 and later see: references. | Structure | 15/Jun/16 6:35 PM |
Bug | TAB-1403 | Use of "conformant" |
It is highly redundant to keep saying "conformant" throughout the specification. You will be defining conformance when you get to the conformance clause.
Ditto for the excessive use of SHALL. For example: 3.2.4 TLS 1.2 Authentication KMIP Port Number You say: ***** Conformant KMIP servers and clients SHALL handle the KMIP port number in in accordance with Basic Authentication KMIP Port Number (3.1.4) of the Basic Authentication Suite. ***** I would say: ***** KMIP servers and clients use the KMIP port number in in accordance with Basic Authentication KMIP Port Number (3.1.4) of the Basic Authentication Suite. ***** Then in the conformance clause, where you list all these section anyway, A KIMP server shall (this section number and others). Reads much more smoothly. |
Minor | Patrick Durusau | Key Management Interoperability Protocol Profiles Version 1.3 | If time permits, recast to remove the redundant "conformant" and excessive use of SHALL and other keywords outside of the conformance clauses. | Style | 15/Jun/16 6:29 PM |
Bug | TAB-1402 | Binding external parties? |
2. Profiles attempts to establish (shall) requirements for profiles and then to impose those requirements on vendors or organizations external to OASIS who create profiles of KMIP.
Sorry, I appreciate the sentiment but it is beyond the charter of any TC to impose requirements on organizations or groups external to OASIS. |
Blocker | Patrick Durusau | Key Management Interoperability Protocol Profiles Version 1.3 | I would delete section 2 in its entirety. | Process | 15/Jun/16 6:23 PM |
Bug | TAB-1401 | RFC and W3C references - incorrect forms |
The RFC and W3C citations in sections 1.2 and 1.3 fail to conform to the citation forms specified by the TC Admin at:
http://docs.oasis-open.org/templates/ietf-rfc-list/ietf-rfc-list.html and http://docs.oasis-open.org/templates/w3c-recommendations-list/w3c-recommendations-list.html respectively. Correct citations to use the OASIS format. |
Minor | Patrick Durusau | Key Management Interoperability Protocol Profiles Version 1.3 | Correct citations in 1.2 and 1.3 to use standard format. | References | 15/Jun/16 6:19 PM |
Generated at Wed Jun 15 22:49:38 UTC 2016 by Patrick Durusau using JIRA 6.2.2#6258-sha1:201243328db078df3cab7b27765d24a31aae57c8. |