[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments on KMIP public review drafts
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings! I woke up this morning to find that the OASIS JIRA had recovered from its bout of indigestion and was once again accepting issues and exporting them. I managed to export the attached comments from individual members of the Technical Advisory Board (TAB) before JIRA could fall on its side again. ;-) Comments on: - - Key Management Interoperability Protocol Specification Version 1.2 - - KMIP Tape Library Profile Version 1.0 - - KMIP Symmetric Key Lifecycle Profile Version 1.0 - - KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0 - - KMIP Suite B Profile Version 1.0 - - KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0 - - KMIP Opaque Managed Object Store Profile Version 1.0 - - KMIP Cryptographic Services Profile Version 1.0 - - KMIP Asymmetric Key Lifecycle Profile Version 1.0 - - KMIP Additional Message Encodings Version 1.0 - - Key Management Interoperability Protocol Usage Guide Version 1.2 - - Key Management Interoperability Protocol Test Cases Version 1.2 are attached. It isn't necessary to acknowledge each comment separately. A single email acknowledging this email will be sufficient. If the TC chooses to “defer” resolution of an issue to a later version, please choose Defer Issue under Available Workflow Actions (after opening the issue). When the TC has acted on these issues, I would appreciate a pointer to the TCs resolution as the TAB is tracking the resolution of comments from TAB members. Hope you are having a great day! Patrick - -- 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/ iQIcBAEBAgAGBQJTLEWCAAoJEAudyeI2QFGo8IUQANt5wd9KlEp+/jI8C8y88ehG NYeo/uW+McxVM32yFoTsDVhFhMH+oiLQiSqBQx4IWu41QwzyDc9pg3kcuEYldwlz mMeMgJlhDrIxnDM8WbtWJ6BeDAwkEcdfQ7PlTS8pymx1PI2MEwAxwWcOqB1pyE65 FJv5BF7Vo6T1gm1J7qqytHV2txu2szwDl5ONc9nPQjK27gYIFXI7cEZVJdjkoClv HrhUJT3C3/+X2CIkFtf4ViLNwx4qDkXOHGuTRsONTWIfyd5/6ejvr4J2oXhh2Mcb /+l/jBzLYpWZ6ntNIWNc1CJUpRG1ZmEsLO9LHMIjT4cGtWYJTLV9FGbPR2A9IHP6 KaiSif8K+cCiokdhZA5tmRhj0ZpJNHw/3fL5aTwGaDeLCzLZtQ1z/FcpofDLoY+S KV8qG2pUbJcxeT62Q27OngUykLExB/QtMkE7JG1ImQ2twVCx/AJEv4D8xogQFdQK FZhodQo1qo9PYPQFOYG4OCghzbnQNXQLgqyUANFF1oT//IARIbX76N059GxGAw8A hzxydizIXf10fcKdZ3+dAKaQggA2JYR/Gp/Ic/c+90x9GMhkRvwQqxffvbwraUdE 9InxRSvp2l6GYiJ5cySlIdiTdFNkTQEc8+cWKFkAtYkzvitZj/h5iT4z0fE9I+VC A6Rwuj7ZCHuynn2NNRae =06AI -----END PGP SIGNATURE-----
,,,,,,,,,,,,,,,,,,,,,,,,,,, OASIS Technical Committees Issue Tracker ,,,,,,,,,,,,,,,,,,,,,,,,,,, Displaying 21 issues at 21/Mar/14 9:39 AM.,,,,,,,,,,,,,,,,,,,,,,,,,,, Project,Key,Summary,Issue Type,Status,Priority,Resolution,Assignee,Reporter,Created,Last Viewed,Updated,Resolved,Affects Version/s,Fix Version/s,Component/s,Due Date,Watchers,Images,Work Ratio,Sub-Tasks,Linked Issues,Environment,Description,Security Level,Labels,Proposal,Resolution Technical Advisory Board,TAB-980 ,References from Test Cases,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,21/Mar/14 8:42 AM,21/Mar/14 9:38 AM,21/Mar/14 8:42 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Technical,"Example from KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0 3.1 reads: ""This section documents the test cases that a client or server conformant to the Symmetric Key Foundry (FIPS140) Profile SHALL support under KMIP Specification 1.0."" 3.1.6 SKFF-M-6-10 reads in part: ***** Create, Locate, Get, Destroy, Locate AES-192 ***** One assumes that ""Create"" refers to some part of KMIP Specification 1.0 and refers to at least one of the test cases that follows in that section. Create should be followed by [KMIP-PROF-1_0:(section number) (title) and then followed by its test case in this profile. Otherwise which test case is for which part of KMIP-PROF-1_0 isn't clear. This is just one example. All of the test cases should have specific references of the form mentioned (to facilitate automated checking) and have the test cases separated from each other.",,,"Create separate references for each reference to a version of KMIP that consist of your key, a section number and the title of the section number, to facilitate automated checking of the references.", Technical Advisory Board,TAB-979 ,Test Case Identification,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,21/Mar/14 8:38 AM,21/Mar/14 8:38 AM,21/Mar/14 8:38 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Structure,"Example from KMIP Tape Library Profile Version 1.0 ***** The Tape Library constructs an identifier string based on the method in 2.3, then requests the server to Locate that string via ASI. A Get is then requested based on the key's unique identifier. The Tape Library MAY update attributes associated with the Symmetric Key Managed Object. The following test case shows extensive use of custom attributes. Custom attributes are not required if the Application Name is unique within the Application Namespace. An implementation may also use custom attributes for vendor-unique purposes, or to improve usability. The test case destroys the key created in the previous test case to clean up after the test. Tape Library implementations MAY not perform this step. ***** This statement is followed by test cases that are not separated from each other or have the ""custom attributes"" or goal of each test described. Every test case should be separated from every other test cases and have the conditions and goal of the test described in prose. This applies to all the test cases in the listed versions.",,,Separate each test case from others and describe its inputs/outputs and/or conditions in prose., Technical Advisory Board,TAB-978 ,Hanging Paragraphs,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,21/Mar/14 8:29 AM,21/Mar/14 8:29 AM,21/Mar/14 8:29 AM,,KMIP Additional Message Encodings Version 1.0,,,,1,,,,,Style,"Sections 1 and 1.1 illustrate the issue with hanging paragraphs. If I say see Section 1, do I mean the paragraphs following section 1 or do I mean that + 1.1 - 1.3? Hanging paragraphs in this draft are: 1, 1.1 2, 2.1 3, 3.1.1 (skipped 3.1, and bad subsection as well) 4, 4.1 (bad subsection) 4.1.6, 4.1.6.1 5, 5.1.1 (skipped 5.1 and bad subsection as well) 6, 6.1 (bad subsection) 6.1.6, 6.1.6.1 7, 7.1.1 (skipped 7.1, and bad subsection as well) 8.4, 8.4.1",,,Re-section the draft to remove hanging paragraphs, Technical Advisory Board,TAB-968 ,Repetition of Appendix B?,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 10:55 AM,20/Mar/14 10:55 AM,20/Mar/14 10:55 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"Unless I am mistaken, Appendix B. KMIP Specification Cross Reference appears in all of the profiles. At the same time, all of the profiles make reference to KMIP-SPEC, where Appendix B also occurs. That is in order to use any of the profiles, the reader must also have a copy of KMIP-SPEC. In the PDF versions, that adds another five (5) pages to each profile. Or a total of 45 pages of duplicated materials, which if printed, are likely to be discarded.",,,Suggest deletion of Appendix B in all profiles in favor of the mapping which already appears in KMIP-SPEC., Technical Advisory Board,TAB-966 ,Test Cases - violation of DRY?,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 10:15 AM,21/Mar/14 9:12 AM,20/Mar/14 10:22 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"After reading over my prior comments on test cases and reviewing the test cases in the drafts, it occurred to me that the test cases follow what is already a normative statement of requirements for each profile. Yes? Taking Tape Profile 1.0 as an example, 2 Tape Library Profile defines all the normative requirements for that profile. Yes? That is to say that if I do everything in 2 Tape Library Profile, I will be conforming to that profile of KMIP-SPEC. Yes? If that's the case, the the test cases violate DRY - Don't Repeat Yourself and are unnecessary. You have said all you need to say. Why say more? I still think the test cases are valuable but would put them in a non-normative document.",,,"Move all test cases to a non-normative document and allow normative requirements to stand by themselves, without repetition.", Technical Advisory Board,TAB-961 ,Conformance based on Test Cases,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 8:42 PM,19/Mar/14 8:49 PM,19/Mar/14 8:42 PM,,KMIP Additional Message Encodings Version 1.0,,,,1,,,,,Normative,"Test cases are referenced in the conformance clauses, but only the test can be normative. As the draft states, the results may vary from those shown. If the results may vary, an implementer can't judge if they have properly pass the test case required for conformance.",,,"As I suggest in another comment, all test cases should be moved to Key Management Interoperability Protocol Test Cases Version 1.2 (or some other non-normative document) and reform conformance clauses to not depend on test cases.", Technical Advisory Board,TAB-960 ,Test Cases - Structure,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 8:40 PM,19/Mar/14 8:40 PM,19/Mar/14 8:40 PM,,KMIP Additional Message Encodings Version 1.0,,,,1,,,,,Normative,"From Key Management Interoperability Protocol Test Cases Version 1.2 1 Introduction reads: ""The purpose of this document is to describe test cases to demonstrate the Key Management Interoperability Protocol (KMIP) [KMIP-SPEC-1_2], [KMIP-SPEC-1_1], and [KMIP-SPEC-1_0]. The test cases illustrate that the concepts within the protocol are sound and how the protocol may be used when implementing KMIP in applications. These test cases are not intended to fully test an implementation of KMIP. There are test cases for v1.0, v1.1 and v1.2 of the protocol."" And 2 KMIP Test Cases reads in part: ""The test cases show one possible way to construct the messages, and the messages shown are not necessarily the only conformant constructions as many items within KMIP are optional and server behavior depends on the server's policy. Support for a test case is predicated on a server matching the test case assumptions and the behavior shown in the request-response pairs."" If that is true for KMIP 1.2, it is certainly also true for KMIP Additional Message Encodings. A more useful location for the test cases would be in Key Management Interoperability Protocol Test Cases Version 1.2 and for the conformance clauses of Additional Message Encodings Profile to be written without reference to test cases. Which as noted above, doesn't really test all of a standard.",,,"Move test cases to Key Management Interoperability Protocol Test Cases Version 1.2, reform conformance clauses to not depend on test cases.", Technical Advisory Board,TAB-959 ,Test Cases - No reference for type constraints,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 8:39 PM,19/Mar/14 8:39 PM,19/Mar/14 8:39 PM,,KMIP Additional Message Encodings Version 1.0,,,,1,,,,,Technical,"The test cases that appear in XML markup contain attribute value restrictions. However, there is no normative citation of value definitions nor is there a schema to enforce those definitions, if given.",,,Normative citation of XML Schema Part 2 plus an XML schema for the test cases as defined are required at a minimum. Usefulness for users also requires the test cases in machine readable XML format., Technical Advisory Board,TAB-958 ,Test Cases - Normative vs. Non-Normative,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 8:38 PM,19/Mar/14 8:38 PM,19/Mar/14 8:38 PM,,KMIP Additional Message Encodings Version 1.0,,,,1,,,,,Normative,"For the three (3) encoding test cases defined, each is preceded with: ***** 3.1.1 The specific list of operations and object types returned in the response MAY vary. 5.1.1 The specific list of operations and object types returned in the response MAY vary. 7.1.1 The specific list of operations and object types returned in the response MAY vary. ***** Assuming the test cases are normative, the responses as given cannot be normative, yet they are not distinguished in the text.",,,Mark all or part of use cases as non-normative as appropriate, Technical Advisory Board,TAB-957 ,Normative versus Non-Normative Text,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 8:32 PM,19/Mar/14 8:32 PM,19/Mar/14 8:32 PM,,KMIP Additional Message Encodings Version 1.0,,,,1,,,,,Normative,No statement of normative versus non-normative text. Which leads to failure to distinguish normative text from non-normative text.,,,"Mark sections as normative vs. non-normative or state at the outset that introductions, notes, examples, etc. are all non-normative.", Technical Advisory Board,TAB-934 ,Citations without section numbers,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 5:30 PM,20/Mar/14 10:03 AM,20/Mar/14 10:02 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, Key Management Interoperability Protocol Usage Guide Version 1.2, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"Just by way of example, 2.2 Suite B minLOS_128 (KMIP Suite B Profile Version 1.0) reads in part: ***** SHALL conform to the Baseline Server profile in [KMIP-PROF] and [KMIP-SPEC] and SHALL support the following Objects [KMIP-SPEC] Certificate [KMIP-SPEC] Symmetric Key [KMIP-SPEC] Public Key [KMIP-SPEC] Private Key [KMIP-SPEC] ***** Citations should include specific section numbers and titles in the cited document. I say that for two reasons: 1) The expert reader (members of this TC) are more likely to recognize an incorrect section citation by its title than by either [KMIP-SPEC] or [KMIP-SPEC:2.2.3]. Say for example if the citation were incorrect and read: [KMIP-SPEC:2.2.7], even an expert reader would be hard pressed to spot that error. On the other hand, if it read: ""Public Key [KMIP-SPEC:2.2.7 Secret Data]"" a TC member would know that wasn't the correct citation. 2) Assuming that all KMIP references between parts of this specification are written KMIP-(key):(number) (title), then it will be possible to automatically validate all of those references. For example, for KMIP-SPEC (the main document), all the section numbers and titles could be automatically extracted and then applied to a document with references to the KMIP-SPEC. By ""applied"" I mean compared to the citations in the text. Where it matches, nothing happens, but, where for whatever reason there is a KMIP cite that does not match, it is highlighted in red (for example). Proofing all the citations, at least to KMIP work, becomes a process of simply scrolling through the document looking for highlights. That won't help if the section citation is correct but substantively incorrect but only a human reader could catch that sort of error. The scripting, assuming reformation of the citations, would not take long and the actual running of the script against all the files would take less than 10 minutes. If not less. I note the work that went into Appendix B and if that effort is to be made on behalf of old users, it is much more necessary for new users of your latest work.",,,"Insert section numbers and titles for all citations of references, thus c. Public Key [KMIP-SPEC:2.2.3 Public Key] noting that ""public key"" appears all over KMIP-SPEC. The section reference makes it clear what is being referenced.", Technical Advisory Board,TAB-919 ,Lack of normative citation XML datatypes,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 12:00 PM,,18/Mar/14 12:00 PM,,KMIP Additional Message Encodings Version 1.0,,,,1,,,,,References,"Numerous references are made to xsd datatypes without a citation to XML Schema part 2, for example, 4.1.6.11, 6.1.6.3, 6.1.6.4, 6.1.6.7, etc. Plus references to XSD. Insert normative references to XML Schema parts 1 and 2 and incorporate specific data types. The W3C citation generator advises the correct citations are: XMLSCHEMA-1 XML Schema Part 1: Structures Second Edition , H. S. Thompson, D. Beech, M. Maloney, N. Mendelsohn, Editors, W3C Recommendation, 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/ . Latest version available at http://www.w3.org/TR/xmlschema-1/ . XMLSCHEMA-2 XML Schema Part 2: Datatypes Second Edition , P. V. Biron, A. Malhotra, Editors, W3C Recommendation, 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ . Latest version available at http://www.w3.org/TR/xmlschema-2/ .",,,Insert normative references to XML schema parts 1 and 2., Technical Advisory Board,TAB-918 ,Normative Reference [XML] incorrect citation.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:55 AM,,18/Mar/14 11:55 AM,,KMIP Additional Message Encodings Version 1.0,,,,1,,,,,References,"1.2 Normative References reads in part: Bray, Tim, et.al. eds, Extensible Markup Language (XML) 1.0 (Fifth Edition), 198 W3C Recommendation 26 November 2008, available at 199 http://www.w3.org/TR/2008/REC-xml-20081126/ http://www.w3.org/2002/01/tr-automation/tr-biblio-ui advises the correct citation: [XML] Extensible Markup Language (XML) 1.0 (Fifth Edition) , T. Bray, J. Paoli, M. , E. Maler, F. Yergeau, Editors, W3C Recommendation, 26 November 2008, http://www.w3.org/TR/2008/REC-xml-20081126/ . Latest version available at http://www.w3.org/TR/xml . BTW, possibly a production error but line numbers are caught up in the citation as well.",,,Correct reference., Technical Advisory Board,TAB-917 ,Normative Reference [RFC4627] obsoleted.,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:54 AM,,18/Mar/14 11:54 AM,,KMIP Additional Message Encodings Version 1.0,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC4627] D. Crockford, The application/json Media Type for JavaScript Object Notation (JSON) July 2006, http:// http://tools.ietf.org/html/rfc4627 The RFC editor's list, shows RFC4627 as superseded by RFC7158, which was superseded by RFC7159. The correct citation for RFC7159: [RFC7159] Bray, T., Ed., ""The JavaScript Object Notation (JSON) Data Interchange Format"", RFC 7159, March 2014. http://www.ietf.org/rfc/rfc7159.txt Update the JSON reference and cite it in a normative part of the text (the introduction usually isn't normative)",,,Update reference., Technical Advisory Board,TAB-916 ,Normative Reference [RFC2818] incorrect citation.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:53 AM,,18/Mar/14 11:53 AM,,KMIP Additional Message Encodings Version 1.0,,,,1,,,,,References,"1.2 Normative References reads in part: E. Rescorla, HTTP over TLS, IETF RFC 2818, May 2000, http://www.ietf.org/rfc/rfc2818.txt The correct citation reads: [RFC2818] Rescorla, E., ""HTTP Over TLS"", RFC 2818, May 2000. http://www.ietf.org/rfc/rfc2818.txt According to the RFC Editor's Bibliographic Table, http://www.rfc-editor.org/in-notes/rfc-ref.txt, and my formatted listing of current RFCs: http://www.durusau.net/standards/rfc/current/",,,Correct reference., Technical Advisory Board,TAB-915 ,Normative Reference [RFC2616] incorrect citation.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:53 AM,,18/Mar/14 11:53 AM,,KMIP Additional Message Encodings Version 1.0,,,,1,,,,,References,"1.2 Normative References reads in part: R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, Hypertext Transfer Protocol -- HTTP/1.1, http://www.ietf.org/rfc/rfc2616.txt, IETF RFC 2616, June 1999. The correct citation reads: [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, ""Hypertext Transfer Protocol -- HTTP/1.1"", RFC 2616, June 1999. http://www.ietf.org/rfc/rfc2616.txt According to the RFC Editor's Bibliographic Table, http://www.rfc-editor.org/in-notes/rfc-ref.txt, and my formatted listing of current RFCs: http://www.durusau.net/standards/rfc/current/",,,Correct reference., Technical Advisory Board,TAB-914 ,Obsoleted Reference,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:51 AM,,18/Mar/14 11:51 AM,,KMIP Additional Message Encodings Version 1.0,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC2246] T. Dierks and C. Allen, The TLS Protocol, Version 1.0, IETF RFC 2246, Jan 1999, http://www.ietf.org/rfc/rfc2246.txt The RFC editor's list at: http://www.rfc-editor.org/in-notes/rfc-ref.txt shows RFC2246 as superseded by RFC4346, which was itself superseded by RFC5246, which should be cited as: [RFC5246] Dierks, T. and E. Rescorla, ""The Transport Layer Security (TLS) Protocol Version 1.2"", RFC 5246, August 2008. http://www.ietf.org/rfc/rfc5246.txt Superseded references should not be cited in current work. Suggest updating the reference. On the other hand, since RFC2246 is not cited in this draft, you probably should just delete it.",,,Update or delete reference., Technical Advisory Board,TAB-913 ,Duplicated Reference,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:50 AM,,18/Mar/14 11:50 AM,,KMIP Additional Message Encodings Version 1.0,,,,1,,,,,References,1.2 Normative References has two citations to RFC2119.,,,Delete one (1) reference to RFC2119., Technical Advisory Board,TAB-803 ,Link Redirects 8,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,25/Feb/14 10:27 AM,,25/Feb/14 10:27 AM,,KMIP Additional Message Encodings Version 1.0,,Public reviews,,0,,,,,Style,"The link checker at: http://validator.w3.org/checklink reports 8 link redirects as follows: ***** Line: 992 http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip redirected to https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 926 http://www.emc.com/ redirected to http://www.emc.com/index.htm Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Lines: 919, 995 http://www.oasis-open.org/committees/kmip/ redirected to https://www.oasis-open.org/committees/kmip/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1089 http://www.oasis-open.org/ redirected to https://www.oasis-open.org/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1094 http://www.oasis-open.org/policies-guidelines/trademark redirected to https://www.oasis-open.org/policies-guidelines/trademark Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 931 http://www.netapp.com/ redirected to http://www.netapp.com/us/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1000 http://www.oasis-open.org/committees/kmip/ipr.php redirected to https://www.oasis-open.org/committees/kmip/ipr.php Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1033 http://www.oasis-open.org/policies-guidelines/ipr redirected to https://www.oasis-open.org/policies-guidelines/ipr Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. *****",,,Update links to use their exact URL., Technical Advisory Board,TAB-802 ,Broken URI fragments,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,25/Feb/14 10:25 AM,,25/Feb/14 10:25 AM,,KMIP Additional Message Encodings Version 1.0,,Public reviews,,0,,,,,Style,"The link checker at: http://validator.w3.org/checklink reports broken URI fragments as follows: ***** Lines: 2791, 2793, 2795 http://docs.oasis-open.org/kmip/spec/v1.0/os/kmip-spec-1.0-os.html Status: 200 OK Some of the links to this resource point to broken URI fragments (such as index.html#fragment). Broken fragments: http://docs.oasis-open.org/kmip/spec/v1.0/os/kmip-spec-1.0-os.html#Ref241992574 (lines 2791, 2793, 2795) ***** This was hard to track because there is no visible HTML link text. The hyperlinks with fragments accompany the values in 4.1.6.7 Enumeration, which reads in part: ***** 4.1.6.7 Enumeration For JSON, value may contain: Number representing the enumeration 32-bit unsigned big-endian value Hex string representation of 32-bit unsigned big-endian value CamelCase enum text as defined in KMIP 9.1.3.2.x ***** The corresponding source code reads: ***** <ul style='margin-top:0in' type=disc> <li class=MsoNormal style='color:black;margin-top:0in;margin-bottom:0in; margin-bottom:.0001pt;text-autospace:none'>Number representing the enumeration 32-bit unsigned big-endian value</li> <li class=MsoNormal style='color:black;margin-top:0in;margin-bottom:0in; margin-bottom:.0001pt;text-autospace:none'>Hex string representation of 32-bit unsigned big-endian value</li> <li class=MsoNormal style='color:black;margin-top:0in;margin-bottom:0in; margin-bottom:.0001pt;text-autospace:none'>CamelCase enum text as defined in <a href=""http://docs.oasis-open.org/kmip/spec/v1.0/os/kmip-spec-1.0-os.html#Ref241992574"";><span style='color:black'>KMIP</span></a><a href=""http://docs.oasis-open.org/kmip/spec/v1.0/os/kmip-spec-1.0-os.html#Ref241992574"";><span style='color:black'> 9.1.3.2.</span></a><a href=""http://docs.oasis-open.org/kmip/spec/v1.0/os/kmip-spec-1.0-os.html#Ref241992574"";><span style='color:black'>x</span></a></li> </ul> *****",,,"If these links are not intentional, remove them. If intentional, please correct.", Technical Advisory Board,TAB-801 ,Broken HTML Links,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,25/Feb/14 10:12 AM,,25/Feb/14 10:13 AM,,KMIP Additional Message Encodings Version 1.0,,Public reviews,,0,,,,,References,"1.3 Non-Normative References reads in part: ***** [KMIP-UG-1_0] Key Management Interoperability Protocol Usage Guide Version 1.0. http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc Committee Note Draft, 1 December 2011 [KMIP-UG-1_1] Key Management Interoperability Protocol Usage Guide Version 1.1. http://docs.oasis-open.org/kmip/ug/v1.1/cn01/kmip-ug-v1.1-cn01.doc Committee Note 01, 27 July 2012 ***** Note that the file names are identical. The link checker at: http://validator.w3.org/checklink reports 404's as follows: ***** Lines: 1412, 1429 http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. error Line: 1446 http://docs.oasis-open.org/kmip/usecases/v1.1/kmip-usecases-v1.1-cnd01.doc Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. ***** The second case of the first link, 1412, 1429 http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc, is a hidden link for [KMIP-UG-1_2].",,,Update the links to point to the correct documents., Generated at Fri Mar 21 13:39:04 UTC 2014 by Patrick Durusau using JIRA 6.1.1#6155-sha1:7188aeec9a6b57d61ea04c52f235f15f55c105e2.,,,,,,,,,,,,,,,,,,,,,,,,,,,
,,,,,,,,,,,,,,,,,,,,,,,,,,, OASIS Technical Committees Issue Tracker ,,,,,,,,,,,,,,,,,,,,,,,,,,, Displaying 16 issues at 21/Mar/14 9:36 AM.,,,,,,,,,,,,,,,,,,,,,,,,,,, Project,Key,Summary,Issue Type,Status,Priority,Resolution,Assignee,Reporter,Created,Last Viewed,Updated,Resolved,Affects Version/s,Fix Version/s,Component/s,Due Date,Watchers,Images,Work Ratio,Sub-Tasks,Linked Issues,Environment,Description,Security Level,Labels,Proposal,Resolution Technical Advisory Board,TAB-980 ,References from Test Cases,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,21/Mar/14 8:42 AM,21/Mar/14 9:36 AM,21/Mar/14 8:42 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Technical,"Example from KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0 3.1 reads: ""This section documents the test cases that a client or server conformant to the Symmetric Key Foundry (FIPS140) Profile SHALL support under KMIP Specification 1.0."" 3.1.6 SKFF-M-6-10 reads in part: ***** Create, Locate, Get, Destroy, Locate AES-192 ***** One assumes that ""Create"" refers to some part of KMIP Specification 1.0 and refers to at least one of the test cases that follows in that section. Create should be followed by [KMIP-PROF-1_0:(section number) (title) and then followed by its test case in this profile. Otherwise which test case is for which part of KMIP-PROF-1_0 isn't clear. This is just one example. All of the test cases should have specific references of the form mentioned (to facilitate automated checking) and have the test cases separated from each other.",,,"Create separate references for each reference to a version of KMIP that consist of your key, a section number and the title of the section number, to facilitate automated checking of the references.", Technical Advisory Board,TAB-979 ,Test Case Identification,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,21/Mar/14 8:38 AM,21/Mar/14 8:38 AM,21/Mar/14 8:38 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Structure,"Example from KMIP Tape Library Profile Version 1.0 ***** The Tape Library constructs an identifier string based on the method in 2.3, then requests the server to Locate that string via ASI. A Get is then requested based on the key's unique identifier. The Tape Library MAY update attributes associated with the Symmetric Key Managed Object. The following test case shows extensive use of custom attributes. Custom attributes are not required if the Application Name is unique within the Application Namespace. An implementation may also use custom attributes for vendor-unique purposes, or to improve usability. The test case destroys the key created in the previous test case to clean up after the test. Tape Library implementations MAY not perform this step. ***** This statement is followed by test cases that are not separated from each other or have the ""custom attributes"" or goal of each test described. Every test case should be separated from every other test cases and have the conditions and goal of the test described in prose. This applies to all the test cases in the listed versions.",,,Separate each test case from others and describe its inputs/outputs and/or conditions in prose., Technical Advisory Board,TAB-977 ,Hanging Paragraphs,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,21/Mar/14 8:28 AM,21/Mar/14 8:28 AM,21/Mar/14 8:28 AM,,KMIP Asymmetric Key Lifecycle Profile Version 1.0,,,,1,,,,,Style,"Sections 1 and 1.1 illustrate the issue with hanging paragraphs. If I say see Section 1, do I mean the paragraphs following section 1 or do I mean that + 1.1 - 1.3? Hanging paragraphs in this draft are: 1, 1.1 2, 2.1 3, 3.1 3.1, 3.1.1 3.2, 3.2.1 3.3, 3.3.1 3.4, 3.4.1 (btw, not a proper subsection. fold into 3.4) 3.5, 3.5.1 (btw, not a proper subsection. fold into 3.5) 3.6, 3.6.1 (btw, not a proper subsection. fold into 3.6) 4.2, 4.2.1 Not a proper subsection means there is no 3.4.2 for example.",,,Re-section the draft to remove hanging paragraphs, Technical Advisory Board,TAB-968 ,Repetition of Appendix B?,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 10:55 AM,20/Mar/14 10:55 AM,20/Mar/14 10:55 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"Unless I am mistaken, Appendix B. KMIP Specification Cross Reference appears in all of the profiles. At the same time, all of the profiles make reference to KMIP-SPEC, where Appendix B also occurs. That is in order to use any of the profiles, the reader must also have a copy of KMIP-SPEC. In the PDF versions, that adds another five (5) pages to each profile. Or a total of 45 pages of duplicated materials, which if printed, are likely to be discarded.",,,Suggest deletion of Appendix B in all profiles in favor of the mapping which already appears in KMIP-SPEC., Technical Advisory Board,TAB-966 ,Test Cases - violation of DRY?,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 10:15 AM,21/Mar/14 9:12 AM,20/Mar/14 10:22 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"After reading over my prior comments on test cases and reviewing the test cases in the drafts, it occurred to me that the test cases follow what is already a normative statement of requirements for each profile. Yes? Taking Tape Profile 1.0 as an example, 2 Tape Library Profile defines all the normative requirements for that profile. Yes? That is to say that if I do everything in 2 Tape Library Profile, I will be conforming to that profile of KMIP-SPEC. Yes? If that's the case, the the test cases violate DRY - Don't Repeat Yourself and are unnecessary. You have said all you need to say. Why say more? I still think the test cases are valuable but would put them in a non-normative document.",,,"Move all test cases to a non-normative document and allow normative requirements to stand by themselves, without repetition.", Technical Advisory Board,TAB-956 ,Conformance based on Test Cases,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 8:31 PM,19/Mar/14 8:31 PM,19/Mar/14 8:31 PM,,KMIP Asymmetric Key Lifecycle Profile Version 1.0,,,,1,,,,,Normative,"Test cases are referenced in the conformance clauses, but only the test can be normative. As the draft states, the results may vary from those shown. If the results may vary, an implementer can't judge if they have properly pass the test case required for conformance.",,,"As I suggest in another comment, all test cases should be moved to Key Management Interoperability Protocol Test Cases Version 1.2 (or some other non-normative document) and reform conformance clauses to not depend on test cases.", Technical Advisory Board,TAB-955 ,Test Cases - Structure,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 8:30 PM,19/Mar/14 8:30 PM,19/Mar/14 8:30 PM,,KMIP Asymmetric Key Lifecycle Profile Version 1.0,,,,1,,,,,Normative,"From Key Management Interoperability Protocol Test Cases Version 1.2 1 Introduction reads: ""The purpose of this document is to describe test cases to demonstrate the Key Management Interoperability Protocol (KMIP) [KMIP-SPEC-1_2], [KMIP-SPEC-1_1], and [KMIP-SPEC-1_0]. The test cases illustrate that the concepts within the protocol are sound and how the protocol may be used when implementing KMIP in applications. These test cases are not intended to fully test an implementation of KMIP. There are test cases for v1.0, v1.1 and v1.2 of the protocol."" And 2 KMIP Test Cases reads in part: ""The test cases show one possible way to construct the messages, and the messages shown are not necessarily the only conformant constructions as many items within KMIP are optional and server behavior depends on the server's policy. Support for a test case is predicated on a server matching the test case assumptions and the behavior shown in the request-response pairs."" If that is true for KMIP 1.2, it is certainly also true for KMIP Asymmetric Key Lifecycle Profile. A more useful location for the test cases would be in Key Management Interoperability Protocol Test Cases Version 1.2 and for the conformance clauses of Asymmetric Key Lifecycle Profile to be written without reference to test cases. Which as noted above, doesn't really test all of a standard.",,,"Move test cases to Key Management Interoperability Protocol Test Cases Version 1.2, reform conformance clauses to not depend on test cases.", Technical Advisory Board,TAB-954 ,Test Cases - No reference for type constraints,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 8:28 PM,19/Mar/14 8:28 PM,19/Mar/14 8:28 PM,,KMIP Asymmetric Key Lifecycle Profile Version 1.0,,,,1,,,,,Technical,"The test cases that appear in XML markup contain attribute value restrictions. However, there is no normative citation of value definitions nor is there a schema to enforce those definitions, if given.",,,Normative citation of XML Schema Part 2 plus an XML schema for the test cases as defined are required at a minimum. Usefulness for users also requires the test cases in machine readable XML format., Technical Advisory Board,TAB-953 ,Test Cases - Normative vs. Non-Normative,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 8:27 PM,19/Mar/14 8:27 PM,19/Mar/14 8:27 PM,,KMIP Asymmetric Key Lifecycle Profile Version 1.0,,,,1,,,,,Normative,"The Note in 3 reads in part: ""the values for the returned items and the Custom Attributes are illustrative. Actual values from a real client system will vary."" If the test cases are normative, then the responses are not and should be so marked. If the test cases are non-normative, then all should be marked as non-normative.",,,Mark all or part of use cases as non-normative as appropriate, Technical Advisory Board,TAB-952 ,"Notes need to be typographically distinct, non-normative",Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 8:26 PM,19/Mar/14 8:26 PM,19/Mar/14 8:26 PM,,KMIP Asymmetric Key Lifecycle Profile Version 1.0,,,,1,,,,,Style,"3 reads in part: ""Note: the values for the returned items and the custom attributes are illustrative. Actual values from a real client system will vary. "" The note is left aligned like other text. ""Note:"" Need to be typographically distinct and are non-normative. Easiest way is to declare all notes as non-normative.",,,Make notes typographically distinct and declare to be non-normative., Technical Advisory Board,TAB-951 ,Normative versus Non-Normative Text,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 8:23 PM,19/Mar/14 8:23 PM,19/Mar/14 8:23 PM,,KMIP Asymmetric Key Lifecycle Profile Version 1.0,,,,1,,,,,Normative,"No statement of normative versus non-normative text. Which leads to failure to distinguish normative text from non-normative text. For example, is the mapping between specifications, Appendix B Normative?",,,"Mark sections as normative vs. non-normative or state at the outset that introductions, notes, examples, etc. are all non-normative.", Technical Advisory Board,TAB-934 ,Citations without section numbers,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 5:30 PM,20/Mar/14 10:03 AM,20/Mar/14 10:02 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, Key Management Interoperability Protocol Usage Guide Version 1.2, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"Just by way of example, 2.2 Suite B minLOS_128 (KMIP Suite B Profile Version 1.0) reads in part: ***** SHALL conform to the Baseline Server profile in [KMIP-PROF] and [KMIP-SPEC] and SHALL support the following Objects [KMIP-SPEC] Certificate [KMIP-SPEC] Symmetric Key [KMIP-SPEC] Public Key [KMIP-SPEC] Private Key [KMIP-SPEC] ***** Citations should include specific section numbers and titles in the cited document. I say that for two reasons: 1) The expert reader (members of this TC) are more likely to recognize an incorrect section citation by its title than by either [KMIP-SPEC] or [KMIP-SPEC:2.2.3]. Say for example if the citation were incorrect and read: [KMIP-SPEC:2.2.7], even an expert reader would be hard pressed to spot that error. On the other hand, if it read: ""Public Key [KMIP-SPEC:2.2.7 Secret Data]"" a TC member would know that wasn't the correct citation. 2) Assuming that all KMIP references between parts of this specification are written KMIP-(key):(number) (title), then it will be possible to automatically validate all of those references. For example, for KMIP-SPEC (the main document), all the section numbers and titles could be automatically extracted and then applied to a document with references to the KMIP-SPEC. By ""applied"" I mean compared to the citations in the text. Where it matches, nothing happens, but, where for whatever reason there is a KMIP cite that does not match, it is highlighted in red (for example). Proofing all the citations, at least to KMIP work, becomes a process of simply scrolling through the document looking for highlights. That won't help if the section citation is correct but substantively incorrect but only a human reader could catch that sort of error. The scripting, assuming reformation of the citations, would not take long and the actual running of the script against all the files would take less than 10 minutes. If not less. I note the work that went into Appendix B and if that effort is to be made on behalf of old users, it is much more necessary for new users of your latest work.",,,"Insert section numbers and titles for all citations of references, thus c. Public Key [KMIP-SPEC:2.2.3 Public Key] noting that ""public key"" appears all over KMIP-SPEC. The section reference makes it clear what is being referenced.", Technical Advisory Board,TAB-912 ,Duplicated Reference,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:49 AM,,18/Mar/14 11:49 AM,,KMIP Asymmetric Key Lifecycle Profile Version 1.0,,,,1,,,,,References,1.2 Normative References has two citations to RFC2119.,,,Delete one (1) reference to RFC2119., Technical Advisory Board,TAB-911 ,Obsoleted Reference,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:49 AM,,18/Mar/14 11:49 AM,,KMIP Asymmetric Key Lifecycle Profile Version 1.0,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC2246] T. Dierks and C. Allen, The TLS Protocol, Version 1.0, IETF RFC 2246, Jan 1999, http://www.ietf.org/rfc/rfc2246.txt The RFC editor's list at: http://www.rfc-editor.org/in-notes/rfc-ref.txt shows RFC2246 as superseded by RFC4346, which was itself superseded by RFC5246, which should be cited as: [RFC5246] Dierks, T. and E. Rescorla, ""The Transport Layer Security (TLS) Protocol Version 1.2"", RFC 5246, August 2008. http://www.ietf.org/rfc/rfc5246.txt Superseded references should not be cited in current work. Suggest updating the reference. On the other hand, since RFC2246 is not cited in this draft, you probably should just delete it.",,,Update or delete reference., Technical Advisory Board,TAB-800 ,Link Redirects 9,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,25/Feb/14 10:09 AM,,25/Feb/14 10:09 AM,,KMIP Asymmetric Key Lifecycle Profile Version 1.0,,Public reviews,,0,,,,,Style,"The link checker at: http://validator.w3.org/checklink reports 9 link redirects as follows: ***** warning Line: 961 http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip redirected to https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 909 http://www.emc.com/ redirected to http://www.emc.com/index.htm Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 923 http://www.thales-esecurity.com/ redirected to https://www.thales-esecurity.com/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1057 http://www.oasis-open.org/ redirected to https://www.oasis-open.org/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Lines: 901, 964 http://www.oasis-open.org/committees/kmip/ redirected to https://www.oasis-open.org/committees/kmip/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1062 http://www.oasis-open.org/policies-guidelines/trademark redirected to https://www.oasis-open.org/policies-guidelines/trademark Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 969 http://www.oasis-open.org/committees/kmip/ipr.php redirected to https://www.oasis-open.org/committees/kmip/ipr.php Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 914 http://www.netapp.com/ redirected to http://www.netapp.com/us/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1001 http://www.oasis-open.org/policies-guidelines/ipr redirected to https://www.oasis-open.org/policies-guidelines/ipr Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. *****",,,Update links to their exact URLs., Technical Advisory Board,TAB-799 ,Broken HTML Links,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,25/Feb/14 10:04 AM,,25/Feb/14 10:07 AM,,KMIP Asymmetric Key Lifecycle Profile Version 1.0,,Public reviews,,0,,,,,References,"1.3 Non-Normative References reads in part: ***** [KMIP-UG-1_0] Key Management Interoperability Protocol Usage Guide Version 1.0. http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc Committee Note Draft, 1 December 2011 [KMIP-UG-1_1] Key Management Interoperability Protocol Usage Guide Version 1.1. http://docs.oasis-open.org/kmip/ug/v1.1/cn01/kmip-ug-v1.1-cn01.doc Committee Note 01, 27 July 2012 ***** Note that the file names are identical. The link checker at: http://validator.w3.org/checklink reports 404's as follows: ***** Lines: 1304, 1321 http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. error Line: 1338 http://docs.oasis-open.org/kmip/usecases/v1.1/kmip-usecases-v1.1-cnd01.doc Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. ***** The second case of the first link, 1304, 1321 http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc, is a hidden link for [KMIP-UG-1_2].",,,Update the links to point to the correct documents., Generated at Fri Mar 21 13:36:54 UTC 2014 by Patrick Durusau using JIRA 6.1.1#6155-sha1:7188aeec9a6b57d61ea04c52f235f15f55c105e2.,,,,,,,,,,,,,,,,,,,,,,,,,,,
,,,,,,,,,,,,,,,,,,,,,,,,,,, OASIS Technical Committees Issue Tracker ,,,,,,,,,,,,,,,,,,,,,,,,,,, Displaying 16 issues at 21/Mar/14 9:34 AM.,,,,,,,,,,,,,,,,,,,,,,,,,,, Project,Key,Summary,Issue Type,Status,Priority,Resolution,Assignee,Reporter,Created,Last Viewed,Updated,Resolved,Affects Version/s,Fix Version/s,Component/s,Due Date,Watchers,Images,Work Ratio,Sub-Tasks,Linked Issues,Environment,Description,Security Level,Labels,Proposal,Resolution Technical Advisory Board,TAB-980 ,References from Test Cases,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,21/Mar/14 8:42 AM,21/Mar/14 9:34 AM,21/Mar/14 8:42 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Technical,"Example from KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0 3.1 reads: ""This section documents the test cases that a client or server conformant to the Symmetric Key Foundry (FIPS140) Profile SHALL support under KMIP Specification 1.0."" 3.1.6 SKFF-M-6-10 reads in part: ***** Create, Locate, Get, Destroy, Locate AES-192 ***** One assumes that ""Create"" refers to some part of KMIP Specification 1.0 and refers to at least one of the test cases that follows in that section. Create should be followed by [KMIP-PROF-1_0:(section number) (title) and then followed by its test case in this profile. Otherwise which test case is for which part of KMIP-PROF-1_0 isn't clear. This is just one example. All of the test cases should have specific references of the form mentioned (to facilitate automated checking) and have the test cases separated from each other.",,,"Create separate references for each reference to a version of KMIP that consist of your key, a section number and the title of the section number, to facilitate automated checking of the references.", Technical Advisory Board,TAB-979 ,Test Case Identification,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,21/Mar/14 8:38 AM,21/Mar/14 8:38 AM,21/Mar/14 8:38 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Structure,"Example from KMIP Tape Library Profile Version 1.0 ***** The Tape Library constructs an identifier string based on the method in 2.3, then requests the server to Locate that string via ASI. A Get is then requested based on the key's unique identifier. The Tape Library MAY update attributes associated with the Symmetric Key Managed Object. The following test case shows extensive use of custom attributes. Custom attributes are not required if the Application Name is unique within the Application Namespace. An implementation may also use custom attributes for vendor-unique purposes, or to improve usability. The test case destroys the key created in the previous test case to clean up after the test. Tape Library implementations MAY not perform this step. ***** This statement is followed by test cases that are not separated from each other or have the ""custom attributes"" or goal of each test described. Every test case should be separated from every other test cases and have the conditions and goal of the test described in prose. This applies to all the test cases in the listed versions.",,,Separate each test case from others and describe its inputs/outputs and/or conditions in prose., Technical Advisory Board,TAB-976 ,Hanging Paragraphs (11),Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 6:49 PM,21/Mar/14 8:25 AM,20/Mar/14 6:49 PM,,KMIP Cryptographic Services Profile Version 1.0,,,,2,,,,,Style,"Sections 1 and 1.1 illustrate the issue with hanging paragraphs. If I say see Section 1, do I mean the paragraphs following section 1 or do I mean that + 1.1 - 1.3? Hanging paragraphs in this draft are: 1, 1.1 2, 2.1 3, 3.1 4, 4.1.1 (skipped 4.1 as well) 5, 5.1 (btw, 5.1 isn't a proper subsection. combine into 5) 6, 6.1 (btw, 6.1 isn't a proper subsection. combine into 6) 7, 7.1.1 (skipped 7.1 as well) 8, 8.1 (btw, 8.1 isn't a proper subsection, combine into 8) 9, 9.1 (btw, 9.1 isn't a proper subsection, combine into 9) 10, 10.1.1 (skipped 10.1 as well) Note production error in HTML on type=""ByteString"" value=""goes off page"" (12 times before 11 Conformance) 11.7, 11.7.1",,,Re-section the draft to remove hanging paragraphs, Technical Advisory Board,TAB-968 ,Repetition of Appendix B?,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 10:55 AM,20/Mar/14 10:55 AM,20/Mar/14 10:55 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"Unless I am mistaken, Appendix B. KMIP Specification Cross Reference appears in all of the profiles. At the same time, all of the profiles make reference to KMIP-SPEC, where Appendix B also occurs. That is in order to use any of the profiles, the reader must also have a copy of KMIP-SPEC. In the PDF versions, that adds another five (5) pages to each profile. Or a total of 45 pages of duplicated materials, which if printed, are likely to be discarded.",,,Suggest deletion of Appendix B in all profiles in favor of the mapping which already appears in KMIP-SPEC., Technical Advisory Board,TAB-966 ,Test Cases - violation of DRY?,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 10:15 AM,21/Mar/14 9:12 AM,20/Mar/14 10:22 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"After reading over my prior comments on test cases and reviewing the test cases in the drafts, it occurred to me that the test cases follow what is already a normative statement of requirements for each profile. Yes? Taking Tape Profile 1.0 as an example, 2 Tape Library Profile defines all the normative requirements for that profile. Yes? That is to say that if I do everything in 2 Tape Library Profile, I will be conforming to that profile of KMIP-SPEC. Yes? If that's the case, the the test cases violate DRY - Don't Repeat Yourself and are unnecessary. You have said all you need to say. Why say more? I still think the test cases are valuable but would put them in a non-normative document.",,,"Move all test cases to a non-normative document and allow normative requirements to stand by themselves, without repetition.", Technical Advisory Board,TAB-962 ,Suggestion for a normative interpretation of Test Cases,Improvement,New,Major,Unresolved,Unassigned,Jacques Durand,19/Mar/14 9:37 PM,,19/Mar/14 10:33 PM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0",,Public reviews,,1,,,,,Normative,"Suggestion for a normative interpretation of Test Cases: Since many KMIP profiles are specified in terms of ""test cases"", a normative interpretation should be given for these test cases. This could be done as a set of rules, that determine what the ""response"" should look like based on the ""Request"" message (assuming the implementation under test, i.e. the conformance target, is the one producing the response). These rules would be generic as much as possible (apply to all test cases in a profile at least). These rules can look like:. 1. Schema rule(s): when receiving a Request that satisfies [XML?] schema X, the implementation MUST send back a response that satisfies [XML?] schema Y. 2. Error rule(s): when receiving a Request that is incorrect (for various reasons) , the implementation MUST (or SHOULD?) send back a response that is of the form.... 3. Processing scope rules: they state what kind of Request content variations (both in terms of atomic values and optional elements) an implementation MUST accept (i.e. process and return something else than an Error). 4. Content dependency rules: these would capture several of the ""test case variation"" response cases, but establish a clear dependency rule with similar or related content in the Request.(i.e. how the Request content determines the Response content) 5. Independent variation rules: hese would restate several of the ""test case variation"" cases, that are independent from the Request content or the dependency of which is not easily expressed nor obvious. But maybe a range of resulting values can be stated. Such normative rules would be part of the specification body, but referred by the COnformance clause. With such rules, the Conformance Clause (for related implementation ) can say: ""[KMIP server] when receiving a Request matching any of the Mandatory test Cases (where ""matching"" allows variations as stated by rules X,Y,Z) , the [server] MUST generate a Response that satisfies the rules 1,2,3,4,5. when applied to the test case response."" instead of: ""support all Mandatory Test Cases (3.1and 3.2 and 3.3), for each supported protocol version (major and minor), returning results in accordance with the test cases."" Note you can then remove the confusingly vague statement: ""Note: the values for the returned items and the custom attributes are illustrative. Actual values from a real client system will vary. "" As this variability would be now defined by normative ""rules"". You can then state that all these test cases (along with their usage or variation rules) are normative content.",,,, Technical Advisory Board,TAB-950 ,Test Cases - Structure,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 8:14 PM,19/Mar/14 8:18 PM,19/Mar/14 8:14 PM,,KMIP Cryptographic Services Profile Version 1.0,,,,1,,,,,Normative,"From Key Management Interoperability Protocol Test Cases Version 1.2 1 Introduction reads: ""The purpose of this document is to describe test cases to demonstrate the Key Management Interoperability Protocol (KMIP) [KMIP-SPEC-1_2], [KMIP-SPEC-1_1], and [KMIP-SPEC-1_0]. The test cases illustrate that the concepts within the protocol are sound and how the protocol may be used when implementing KMIP in applications. These test cases are not intended to fully test an implementation of KMIP. There are test cases for v1.0, v1.1 and v1.2 of the protocol."" And 2 KMIP Test Cases reads in part: ""The test cases show one possible way to construct the messages, and the messages shown are not necessarily the only conformant constructions as many items within KMIP are optional and server behavior depends on the server's policy. Support for a test case is predicated on a server matching the test case assumptions and the behavior shown in the request-response pairs."" If that is true for KMIP 1.2, it is certainly also true for KMIP Cryptographic Services Profile Version 1.0 A more useful location for the test cases would be in Key Management Interoperability Protocol Test Cases Version 1.2 and for the conformance clauses of Cryptographic Services to be written without reference to test cases. Which as noted above, doesn't really test all of a standard.",,,"Move test cases to Key Management Interoperability Protocol Test Cases Version 1.2, reform conformance clauses to not depend on test cases.", Technical Advisory Board,TAB-949 ,Test Cases - No reference for type constraints,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 8:11 PM,19/Mar/14 8:11 PM,19/Mar/14 8:11 PM,,KMIP Cryptographic Services Profile Version 1.0,,,,1,,,,,Technical,"The test cases that appear in XML markup contain attribute value restrictions. However, there is no normative citation of value definitions nor is there a schema to enforce those definitions, if given.",,,Normative citation of XML Schema Part 2 plus an XML schema for the test cases as defined are required at a minimum. Usefulness for users also requires the test cases in machine readable XML format., Technical Advisory Board,TAB-948 ,Test Cases - Normative vs. Non-Normative,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 8:10 PM,19/Mar/14 8:10 PM,19/Mar/14 8:10 PM,,KMIP Cryptographic Services Profile Version 1.0,,,,1,,,,,Normative,"This draft lacks a statement about results being ""illustrative?"" Is that correct? That both the tests and the results are both normative?",,,Confirm whether test cases and results are both normative., Technical Advisory Board,TAB-947 ,Normative versus Non-Normative Text,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 8:06 PM,19/Mar/14 8:06 PM,19/Mar/14 8:06 PM,,KMIP Cryptographic Services Profile Version 1.0,,,,1,,,,,Normative,"No statement of normative versus non-normative text. Which leads to failure to distinguish normative text from non-normative text. For example, is the mapping between specifications, Appendix B Normative?",,,"Mark sections as normative vs. non-normative or state at the outset that introductions, notes, examples, etc. are all non-normative.", Technical Advisory Board,TAB-934 ,Citations without section numbers,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 5:30 PM,20/Mar/14 10:03 AM,20/Mar/14 10:02 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, Key Management Interoperability Protocol Usage Guide Version 1.2, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"Just by way of example, 2.2 Suite B minLOS_128 (KMIP Suite B Profile Version 1.0) reads in part: ***** SHALL conform to the Baseline Server profile in [KMIP-PROF] and [KMIP-SPEC] and SHALL support the following Objects [KMIP-SPEC] Certificate [KMIP-SPEC] Symmetric Key [KMIP-SPEC] Public Key [KMIP-SPEC] Private Key [KMIP-SPEC] ***** Citations should include specific section numbers and titles in the cited document. I say that for two reasons: 1) The expert reader (members of this TC) are more likely to recognize an incorrect section citation by its title than by either [KMIP-SPEC] or [KMIP-SPEC:2.2.3]. Say for example if the citation were incorrect and read: [KMIP-SPEC:2.2.7], even an expert reader would be hard pressed to spot that error. On the other hand, if it read: ""Public Key [KMIP-SPEC:2.2.7 Secret Data]"" a TC member would know that wasn't the correct citation. 2) Assuming that all KMIP references between parts of this specification are written KMIP-(key):(number) (title), then it will be possible to automatically validate all of those references. For example, for KMIP-SPEC (the main document), all the section numbers and titles could be automatically extracted and then applied to a document with references to the KMIP-SPEC. By ""applied"" I mean compared to the citations in the text. Where it matches, nothing happens, but, where for whatever reason there is a KMIP cite that does not match, it is highlighted in red (for example). Proofing all the citations, at least to KMIP work, becomes a process of simply scrolling through the document looking for highlights. That won't help if the section citation is correct but substantively incorrect but only a human reader could catch that sort of error. The scripting, assuming reformation of the citations, would not take long and the actual running of the script against all the files would take less than 10 minutes. If not less. I note the work that went into Appendix B and if that effort is to be made on behalf of old users, it is much more necessary for new users of your latest work.",,,"Insert section numbers and titles for all citations of references, thus c. Public Key [KMIP-SPEC:2.2.3 Public Key] noting that ""public key"" appears all over KMIP-SPEC. The section reference makes it clear what is being referenced.", Technical Advisory Board,TAB-910 ,Obsoleted Reference,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:48 AM,,18/Mar/14 11:48 AM,,KMIP Cryptographic Services Profile Version 1.0,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC2246] T. Dierks and C. Allen, The TLS Protocol, Version 1.0, IETF RFC 2246, Jan 1999, http://www.ietf.org/rfc/rfc2246.txt The RFC editor's list at: http://www.rfc-editor.org/in-notes/rfc-ref.txt shows RFC2246 as superseded by RFC4346, which was itself superseded by RFC5246, which should be cited as: [RFC5246] Dierks, T. and E. Rescorla, ""The Transport Layer Security (TLS) Protocol Version 1.2"", RFC 5246, August 2008. http://www.ietf.org/rfc/rfc5246.txt Superseded references should not be cited in current work. Suggest updating the reference. On the other hand, since RFC2246 is not cited in this draft, you probably should just delete it.",,,Update or delete reference., Technical Advisory Board,TAB-841 ,Confusing redundancy in conformance statements outside conformance clauses,Improvement,New,Major,Unresolved,Unassigned,Jacques Durand,17/Mar/14 9:35 PM,,17/Mar/14 9:35 PM,,KMIP Cryptographic Services Profile Version 1.0,,Public reviews,,1,,,,,Structure,"Confusing redundancy in conformance statements outside conformance clause: ""section 11.1 Base Cryptographic Server Conformance"" is clearly redundant with : ""section 2.1 Base Cryptographic Server"" Both pretend to be a conformance clause for Base Cryptographic Server. Same for the Client statements. Sections 2 and 3 should merge into the Conformance section. Same for all other ""Profiles"" in this doc. They are introduced by conformance statements that should be in conformance clauses at the end. All these ""profiles"" should instead have a brief intro of the kind: "" This [Server/Client] profile is defined by the ability of the implementation to interpret properly the following test cases (see ""normative interpretation"" of test cases) . Conformance to this profile is defined in the Conformance section."" (NOTE: see another comment made about the necessity to define what a ""normative interpretation"" of these test cases is - i.e. how to ""read"" these test cases, and what it means to satisfy them -, as these are used in a conformance clause and therefore parts of the specification itself and of the definition of its conformance, not part of of a test suite to *verify* a conformance definition otherwise self-sufficient and independent from any test case by itself. This is not quite the same thing.)",,,, Technical Advisory Board,TAB-840 ,Unclear what â??supporting a [mandatory] testâ?? means,Improvement,New,Critical,Unresolved,Unassigned,Jacques Durand,17/Mar/14 9:08 PM,,17/Mar/14 9:08 PM,,KMIP Cryptographic Services Profile Version 1.0,,Public reviews,,1,,,,,Conformance,"In this document, there is hardly a hint on what â??supporting a [mandatory] testâ?? means. Especially because this is part of a conformance requirement, it should be clearly defined how to interpret all these test data in order to â??supportâ?? the test. Which party is supposed to send the RequestMessages? The ResponseMessages? What does â??Time 0, 1, 2,,,â?? means? Where are the XML schemas defined? A â??normative interpretationâ?? of these Test Cases should be defined. What may vary from the actual XML instances, what may not (as in 11.7) should be part of that â??normative interpretationâ?? of Test Cases. There seems to be a Committee Note (http://docs.oasis-open.org/kmip/testcases/v1.1/cn01/kmip-testcases-v1.1-cn01.doc). explaining more about these test cases, but it is not normative and cannot be referred to by a conformance clause. And also this CN does not explain how to interpret â??tagsâ?? into XML.",,,, Technical Advisory Board,TAB-798 ,Link Redirects 8,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,25/Feb/14 10:02 AM,,25/Feb/14 10:02 AM,,KMIP Cryptographic Services Profile Version 1.0,,Public reviews,,0,,,,,Style,"The link checker at: http://validator.w3.org/checklink reports 8 link redirects as follows: ***** Line: 988 http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip redirected to https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 927 http://www.emc.com/ redirected to http://www.emc.com/index.htm Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Lines: 919, 991 http://www.oasis-open.org/committees/kmip/ redirected to https://www.oasis-open.org/committees/kmip/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1081 http://www.oasis-open.org/ redirected to https://www.oasis-open.org/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1086 http://www.oasis-open.org/policies-guidelines/trademark redirected to https://www.oasis-open.org/policies-guidelines/trademark Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 932 http://www.netapp.com/ redirected to http://www.netapp.com/us/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 996 http://www.oasis-open.org/committees/kmip/ipr.php redirected to https://www.oasis-open.org/committees/kmip/ipr.php Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1026 http://www.oasis-open.org/policies-guidelines/ipr redirected to https://www.oasis-open.org/policies-guidelines/ipr Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. *****",,,Update links to their exact URLs., Technical Advisory Board,TAB-797 ,Broken HTML Links,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,25/Feb/14 9:59 AM,,25/Feb/14 10:00 AM,,KMIP Cryptographic Services Profile Version 1.0,,Public reviews,,0,,,,,References,"1.3 Non-Normative References reads in part: ***** [KMIP-UG-1_0] Key Management Interoperability Protocol Usage Guide Version 1.0. http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc Committee Note Draft, 1 December 2011 [KMIP-UG-1_1] Key Management Interoperability Protocol Usage Guide Version 1.1. http://docs.oasis-open.org/kmip/ug/v1.1/cn01/kmip-ug-v1.1-cn01.doc Committee Note 01, 27 July 2012 ***** Note that the file names are identical. The link checker at: http://validator.w3.org/checklink reports 404's as follows: ***** Lines: 1290, 1307 http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. error Line: 1324 http://docs.oasis-open.org/kmip/usecases/v1.1/kmip-usecases-v1.1-cnd01.doc Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. ***** The second case of the first link, 1290, 1307 http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc, is a hidden link for [KMIP-UG-1_2].",,,Update the links to point to the correct documents., Generated at Fri Mar 21 13:34:52 UTC 2014 by Patrick Durusau using JIRA 6.1.1#6155-sha1:7188aeec9a6b57d61ea04c52f235f15f55c105e2.,,,,,,,,,,,,,,,,,,,,,,,,,,,
,,,,,,,,,,,,,,,,,,,,,,,,,,,
OASIS Technical Committees Issue Tracker ,,,,,,,,,,,,,,,,,,,,,,,,,,,
Displaying 59 issues at 21/Mar/14 9:18 AM.,,,,,,,,,,,,,,,,,,,,,,,,,,,
Project,Key,Summary,Issue Type,Status,Priority,Resolution,Assignee,Reporter,Created,Last Viewed,Updated,Resolved,Affects Version/s,Fix Version/s,Component/s,Due Date,Watchers,Images,Work Ratio,Sub-Tasks,Linked Issues,Environment,Description,Security Level,Labels,Proposal,Resolution
Technical Advisory Board,TAB-967 ,Hanging Paragraphs (19),Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 10:47 AM,21/Mar/14 9:18 AM,20/Mar/14 10:47 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,Style,"Sections 1 and 1.1 illustrate the issue with hanging paragraphs. If I say see Section 1, do I mean the two paragraphs following section 1 or do I mean that + 1.1 - 1.3? Hanging paragraphs in this draft: 1, 1.1 2, 2.1 2.1, 2.1.1 2.1.7, 2.1.7.1 2.2, 2.2.1 3, 3.1 3.18, 3.18.1 3.18.2, 3.18.2.1 4, 4.1 5, 5.1 6, 6.1 7, 7.1 9, 9.1 9.1, 9.1.1 9.1.1, 9.1.1.1 9.1.3, 9.1.3.1 9.1.3.2, 9.1.3.2.1 9.1.3.3, 9.1.3.3.1 11, 11.1",,,Re-section the draft to remove hanging paragraphs,
Technical Advisory Board,TAB-889 ,Subsections as lists?,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:41 AM,19/Mar/14 5:14 PM,18/Mar/14 10:41 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,Style,"9.1.1 TTLV Encoding Fields reads in part: Every Data object encoded by the TTLV scheme consists of four items, in order: In addition to being a hanging paragraph, it is followed by four subsections of 9.1.1.1 Item Tag, 9.1.1.2 Item Type, 9.1.1.3 Item Length, and 91.1.4 Item Value. Which requires the reader to make a leap to connect the following subsections with 9.1.1 To avoid both the leap by the reader and the hanging paragraph, why not: 9.1.1 TTLV Encoding Fields 9.1.1.1 General Every Data object encoded by the TTLV scheme consists of Item Tag (9.1.1.2), Item Type (9.1.1.3), Item Length (9.1.1.4), and Item Value (9.1.1.5), in that order. 9.1.1.2 - 9.1.1.5 follow here. I would make the (9.1.12) into hyperlinks.",,,Avoid hanging paragraph and use of sub-sections as list as shown.,
Technical Advisory Board,TAB-888 ,General Comment on non-cited RFCs,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:39 AM,,18/Mar/14 10:39 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"I checked for citation of RFCs by searching for the keys you defined for each one, hence [RFC6818] but without the brackets, just in case it was cited as a sub-string. All of the citations of the non-cited RFCs are incorrect but I omitted the corrected text on the assumption that you will be deleting non-cited references. Should you decide to cite any of the non-cited RFCs, please consult: The RFC Editor's Bibliographic Table, http://www.rfc-editor.org/in-notes/rfc-ref.txt, or my formatted listing of current RFCs: http://www.durusau.net/standards/rfc/current/ for the correct citations.",,,"If non-cited RFCs become cited, use the correct citations for each one.",
Technical Advisory Board,TAB-887 ,"ANSI, X9.63 - question",Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:33 AM,,18/Mar/14 10:33 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"Appendix E. Acronyms Is Appendix E normative? I ask because it is the only place where: [X9.63] ANSI, X9.63: Public Key Cryptography for the Financial Services Industry, Key Agreement and Key Transport Using Elliptic Curve Cryptography, 2011. is cited in this draft. If Appendix E is normative, then this can remain a normative reference. If Appendix E is non-normative, this reference should be moved into non-normative refernces.",,,Citation is normative or non-normative depending upon your answer on Appendix E. Leave or move as appropriate.,
Technical Advisory Board,TAB-886 ,Normative Reference [X9.57] Not used.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:32 AM,,18/Mar/14 10:32 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"X9.57 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-885 ,Normative Reference [X9.24-1] Not used.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:31 AM,,18/Mar/14 10:31 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"X9.24-1 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-884 ,Normative Reference [SP800-67] Not used.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:31 AM,,18/Mar/14 10:31 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"SP800-67 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-883 ,Normative Reference [SP800-56B] Not used.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:30 AM,,18/Mar/14 10:30 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"SP800-56B is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-882 ,Normative Reference [SP800-38F] Not used.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:29 AM,,18/Mar/14 10:29 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"SP800-38F is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-881 ,Normative Reference [SP800-38E] Not used.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:29 AM,,18/Mar/14 10:29 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"SP800-38E is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-880 ,Normative Reference [SP800-38C] Not used.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:28 AM,,18/Mar/14 10:28 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"SP800-38C is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-879 ,Normative Reference [SP800-38B] Not used.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:28 AM,,18/Mar/14 10:28 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"SP800-38B is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-878 ,Normative Reference [RFC6818] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:27 AM,,18/Mar/14 10:27 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"RFC6818 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-877 ,Normative Reference [RFC6402] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:27 AM,,18/Mar/14 10:27 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"RFC6402 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-876 ,Normative Reference [RFC5756] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:26 AM,,18/Mar/14 10:26 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"RFC5756 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-875 ,Normative Reference [RFC5649] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:25 AM,,18/Mar/14 10:25 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"RFC5649 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-874 ,Normative Reference [RFC5280] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:25 AM,,18/Mar/14 10:25 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"RFC5280 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-873 ,Normative Reference [RFC5272] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:24 AM,,18/Mar/14 10:24 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"RFC5272 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-872 ,Normative Reference [RFC5208] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:24 AM,,18/Mar/14 10:24 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"RFC5208 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-871 ,Normative Reference [RFC4949] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:23 AM,,18/Mar/14 10:23 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"RFC4949 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-870 ,Normative Reference [RFC4880] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:23 AM,,18/Mar/14 10:23 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"RFC4880 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-869 ,Normative Reference [RFC4868] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:22 AM,,18/Mar/14 10:22 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"RFC4868 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-868 ,Normative Reference [RFC4211] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:21 AM,,18/Mar/14 10:21 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"RFC4211 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-867 ,Normative Reference [RFC2510] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:21 AM,,18/Mar/14 10:21 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"RFC2510 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-866 ,Normative Reference [RFC4210] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:20 AM,,18/Mar/14 10:20 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"RFC4210 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-865 ,"Normative Reference [RFC4210], confusion of RFC with its superseding RFC",Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:19 AM,,18/Mar/14 10:19 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC4210] C. Adams, S. Farrell, T. Kause and T. Mononen, Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP), IETF RFC 2510, September 2005, http://www.ietf.org/rfc/rfc4210.txt. Attempting to cite both RFC2510 and its superceding RFC4210. The correct citation for RFC2510 (superseded by RFC4210) reads: [RFC2510] Adams, C. and S. Farrell, ""Internet X.509 Public Key Infrastructure Certificate Management Protocols"", RFC 2510, March 1999. http://www.ietf.org/rfc/rfc2510.txt As a superceded RFC, RFC2510 should not appear as a normative reference. The correct citation for RFC4210 reads: Adams, C., Farrell, S., Kause, T., and T. Mononen, ""Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)"", RFC 4210, September 2005. According to the RFC Editor's Bibliographic Table, http://www.rfc-editor.org/in-notes/rfc-ref.txt, and my formatted listing of current RFCs: http://www.durusau.net/standards/rfc/current/",,,Correct citation.,
Technical Advisory Board,TAB-864 ,Normative Reference [RFC4055] incorrect citation.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:18 AM,,18/Mar/14 10:18 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC4055] J. Schadd, B. Kaliski, and R, Housley, Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, IETF RFC 4055, June 2055, http://www.ietf.org/rfc/rfc4055.txt. The correct citation reads: RFC4055] Schaad, J., Kaliski, B., and R. Housley, ""Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"", RFC 4055, June 2005. http://www.ietf.org/rfc/rfc4055.txt According to the RFC Editor's Bibliographic Table, http://www.rfc-editor.org/in-notes/rfc-ref.txt, and my formatted listing of current RFCs: http://www.durusau.net/standards/rfc/current/",,,Correct citation.,
Technical Advisory Board,TAB-863 ,Normative References [RFC3686] - References collapsed into single listing,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:18 AM,,18/Mar/14 10:18 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC3686] R. Housley, Using Advanced Encryption Standard (AES) Counter Mode with IPsec Encapsulating Security Payload (ESP), IETF RFC 3686, January 2004, http://www.ietf.org/rfc/rfc3686.txt. [RFC4055] J. Schadd, B. Kaliski, and R, Housley, Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, IETF RFC 4055, June 2055, http://www.ietf.org/rfc/rfc4055.txt. The citations should be broken into separate listing and [RFC4055] should be place in its proper numerical order.",,,"Separate citations, re-order.",
Technical Advisory Board,TAB-862 ,Normative Reference [RFC3686] incorrect citation.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:17 AM,,18/Mar/14 10:17 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC3686] R. Housley, Using Advanced Encryption Standard (AES) Counter Mode with IPsec Encapsulating Security Payload (ESP), IETF RFC 3686, January 2004, http://www.ietf.org/rfc/rfc3686.txt. The correct citation reads: [RFC3686] Housley, R., ""Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)"", RFC 3686, January 2004. http://www.ietf.org/rfc/rfc3686.txt According to the RFC Editor's Bibliographic Table, http://www.rfc-editor.org/in-notes/rfc-ref.txt, and my formatted listing of current RFCs: http://www.durusau.net/standards/rfc/current/",,,Correct citation.,
Technical Advisory Board,TAB-861 ,Normative Reference [RFC3647] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:16 AM,,18/Mar/14 10:16 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"RFC3647 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-860 ,Normative Reference [RFC3629] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:15 AM,,18/Mar/14 10:15 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"RFC3629 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-859 ,Normative Reference [RFC3447] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:14 AM,,18/Mar/14 10:14 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"RFC3447 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-858 ,Normative Reference [RFC3394] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:14 AM,,18/Mar/14 10:14 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"RFC3394 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-857 ,Normative Reference [RFC2986] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:13 AM,,18/Mar/14 10:13 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"RFC2986 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete citation.,
Technical Advisory Board,TAB-856 ,Normative Reference [RFC2898] incorrect citation.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:12 AM,,18/Mar/14 10:12 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC2898] B. Kaliski, PKCS #5: Password-Based Cryptography Specification Version 2.0, IETF RFC 2898, September 2000, http://www.ietf.org/rfc/rfc2898.txt. The correct citation reads: [RFC2898] Kaliski, B., ""PKCS #5: Password-Based Cryptography Specification Version 2.0"", RFC 2898, September 2000. http://www.ietf.org/rfc/rfc2898.txt According to the RFC Editor's Bibliographic Table, http://www.rfc-editor.org/in-notes/rfc-ref.txt, and my formatted listing of current RFCs: http://www.durusau.net/standards/rfc/current/",,,Correct citation.,
Technical Advisory Board,TAB-855 ,Normative Reference [RFC2315] incorrect citation.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:09 AM,,18/Mar/14 10:09 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC2315] B. Kaliski, PKCS #7: Cryptographic Message Syntax Version 1.5, IETF RFC2315, March 1998, http://www.rfc-editor.org/rfc/rfc2315.txt. The correct citation reads: [RFC2315] Kaliski, B., ""PKCS #7: Cryptographic Message Syntax Version 1.5"", RFC 2315, March 1998. http://www.ietf.org/rfc/rfc2315.txt According to the RFC Editor's Bibliographic Table, http://www.rfc-editor.org/in-notes/rfc-ref.txt, and my formatted listing of current RFCs: http://www.durusau.net/standards/rfc/current/",,,Correct citation.,
Technical Advisory Board,TAB-854 ,Normative Reference [RFC2119] incorrect citation.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:09 AM,,18/Mar/14 10:09 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, March 1997, http://www.ietf.org/rfc/rfc2119.txt. The correct citation reads: [RFC2119] Bradner, S., ""Key words for use in RFCs to Indicate Requirement Levels"", BCP 14, RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt According to the RFC Editor's Bibliographic Table, http://www.rfc-editor.org/in-notes/rfc-ref.txt, and my formatted listing of current RFCs: http://www.durusau.net/standards/rfc/current/",,,Correct citation.,
Technical Advisory Board,TAB-853 ,Normative Reference [RFC2104] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:08 AM,,18/Mar/14 10:08 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"1.2 Normative References reads in part: H. Krawczyk, M. Bellare, R. Canetti, HMAC: Keyed-Hashing for Message Authentication, IETF RFC 2104, February 1997, http://www.ietf.org/rfc/rfc2104.txt. RFC2104 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Suggest deletion of non-cited reference.,
Technical Advisory Board,TAB-852 ,Normative Reference [RFC1945] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:07 AM,,18/Mar/14 10:07 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"1.2 Normative References reads in part: T. Berners-Lee, R. Fielding, H. Frystyk, Hypertext Transfer Protocol -- HTTP/1.0, IETF RFC 1945, May 1996, http://www.ietf.org/rfc/rfc1945.txt. RFC1945 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Suggest deletion of non-cited reference.,
Technical Advisory Board,TAB-851 ,Normative Reference [RFC1424] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:07 AM,,18/Mar/14 10:07 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC1424] B. Kaliski, Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services, IETF RFC 1424, Feb 1993, http://www.ietf.org/rfc/rfc1424.txt. RFC1424 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Suggest deletion of non-cited reference.,
Technical Advisory Board,TAB-850 ,Normative Reference [RFC1421] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:06 AM,,18/Mar/14 10:06 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC1421] J. Linn, Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures, IETF RFC 1421, February 1993, http://www.ietf.org/rfc/rfc1421.txt. RFC1421 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Suggest deletion of non-cited reference.,
Technical Advisory Board,TAB-849 ,Normative Reference [RFC1321] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:06 AM,,18/Mar/14 10:06 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC1321] R. Rivest, The MD5 Message-Digest Algorithm, IETF RFC 1321, April 1992, http://www.ietf.org/rfc/rfc1321.txt. RFC1321 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Suggest deletion of non-cited reference.,
Technical Advisory Board,TAB-848 ,Normative Reference [RFC1320] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:05 AM,,18/Mar/14 10:05 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC1320] R. Rivest, The MD4 Message-Digest Algorithm, IETF RFC 1320, April 1992, http://www.ietf.org/rfc/rfc1320.txt. RFC1320 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Suggest deletion of non-cited reference.,
Technical Advisory Board,TAB-847 ,Normative Reference [RFC1319] not cited.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:04 AM,,18/Mar/14 10:04 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC1319] B. Kaliski, The MD2 Message-Digest Algorithm, IETF RFC 1319, Apr 1992, http://www.ietf.org/rfc/rfc1319.txt. RFC1319 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Suggest deletion of non-cited reference.,
Technical Advisory Board,TAB-846 ,1.2 Normative References - Broken RSA Links,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:03 AM,,18/Mar/14 10:03 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"Broken RSA Links (5) 1.2 Normative References reads in part: ***** [PKCS#1] RSA Laboratories, PKCS #1 v2.1: RSA Cryptography Standard, June 14, 2002, http://www.rsa.com/rsalabs/node.asp?id=2125. [PKCS#5] RSA Laboratories, PKCS #5 v2.1: Password-Based Cryptography Standard, October 5, 2006, http://www.rsa.com/rsalabs/node.asp?id=2127. [PKCS#7] RSA Laboratories, PKCS#7 v1.5: Cryptographic Message Syntax Standard, November 1, 1993, http://www.rsa.com/rsalabs/node.asp?id=2129. [PKCS#8] RSA Laboratories, PKCS#8 v1.2: Private-Key Information Syntax Standard, November 1, 1993, http://www.rsa.com/rsalabs/node.asp?id=2130. [PKCS#10] RSA Laboratories, PKCS #10 v1.7: Certification Request Syntax Standard, May 26, 2000, http://www.rsa.com/rsalabs/node.asp?id=2132. ***** None of those links resolve to the cited material. They all resolve to: http://www.emc.com/domains/rsa/index.htm?id=2125 (with the appropriate id number at the end of the hyperlink)",,,Supply correct links for RSA Laboratories standards cited.,
Technical Advisory Board,TAB-845 ,1.2 Normative References - OASIS Login required?,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:02 AM,,18/Mar/14 10:08 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,2,,,,,References,"1.2 Normative References reads in part: [KMIP-Prof] Key Management Interoperability Protocol Profiles Version 1.2 wd02, June 27, 2013, https://www.oasis-open.org/apps/org/workgroup/kmip/download.php/49689/kmip-profiles-v1.2-wd02.doc. The URL given requires an OASIS login to obtain the document. Did you intend to base conformance on a document that isn't available to others?",,,Supply a public URL for KMIP-Prof.,
Technical Advisory Board,TAB-844 ,1.2 Normative References - out dated reference,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:00 AM,,18/Mar/14 10:00 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,References,"1.2 Normative References reads in part: [ECC-Brainpool] ECC Brainpool Standard Curves and Curve Generation v. 1.0.19.10.2005, http://www.ecc-brainpool.org/download/Domain-parameters.pdf. Was there some reason to not cite: [RFC5639] Lochter, M. and J. Merkle, ""Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation"", RFC 5639, March 2010. http://www.ietf.org/rfc/rfc5639.txt, which relies on ECC-Brainpool as a source? You cite [ECC-Brainpool] at 9.1.3.2.5 as a ""recommended"" curve. Would the later reference be better?",,,"Adopt RFC5639 as the appropriate reference and update normative reference to: [RFC5639] Lochter, M. and J. Merkle, ""Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation"", RFC 5639, March 2010. http://www.ietf.org/rfc/rfc5639.txt Delete the current reference.",
Technical Advisory Board,TAB-843 ,Table numbering and captions,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 9:51 AM,,18/Mar/14 9:51 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,Style,"Table numbering and captions should be centered under the appropriate table. See Table 1: Terminology for instance, which is aligned on the left margin. The better practice is centering as was done in KMIP Additional Message Encodings Version 1.0, 4.1.3 Normalizing Names, centered: ""Example python name normalization code""",,,Center table numbers and captions,
Technical Advisory Board,TAB-842 ,Normative versus Non-Normative Text,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 9:48 AM,19/Mar/14 5:15 PM,18/Mar/14 9:48 AM,,Key Management Interoperability Protocol Specification Version 1.2,,,,1,,,,,Normative,"No statement of normative versus non-normative text. Which leads to failure to distinguish normative text from non-normative text. True enough, tables in Appendices B, C, D are marked: ""This table is not normative."" but the same statement is omitted from 9.1.2 Examples, which appears to be non-normative text as well. I assume the Introduction is non-normative? Other examples should be non-normative as well.",,,"Mark sections as normative vs. non-normative or state at the outset that introductions, notes, examples, etc. are all non-normative.",
Technical Advisory Board,TAB-839 ,XML listed in acronyms but not used,Improvement,New,Minor,Unresolved,Unassigned,Jacques Durand,17/Mar/14 8:57 PM,,17/Mar/14 8:57 PM,,Key Management Interoperability Protocol Specification Version 1.2,,Public reviews,,1,,,,,Technical,"""XML"" listed in Appendix E but not used",,,,
Technical Advisory Board,TAB-838 ,Self-referencing and confusing statement in KMIP Client conformance clause,Improvement,New,Major,Unresolved,Unassigned,Jacques Durand,17/Mar/14 8:14 PM,,17/Mar/14 8:14 PM,,Key Management Interoperability Protocol Specification Version 1.2,,Public reviews,,1,,,,,,"Self-referencing and confusing statement in KMIP Client conformance clause: In 12.2: "" A KMIP client implementation SHALL be a conforming KMIP Client ."" Is this an attempt to define what is an [KMIP Client ] implementation ? That should be done independently from the notion of conformance, i.e. in a ""functional"" way, e.g. in a glossary. Then the conformance clause would come in later and say: "" a conforming KMIP Client implementation SHALL satisfy...X, Y Z"". But in any case, the conformance clause should avoid referring to itself (""... SHALL be a conforming KMIP Client ."" where the way to ""conform"" is precisely the object of the clause containing that statement.) Or, if you want to reserve the name ""KMIP Client "" exclusively to designate implementations that fulfill this conformance profile, then assuming that you have previously defined a notion of ""Key management Client "" (actually used in the specification narrative, but undefined), you could say as a general introduction to the KMIP Client conformance profile: ""In order to qualify as a KMIP Client , a Key management Client implementation SHALL satisfy X, Y Z"". Where X, Y, Z are the actual meat of the conformance clause for KMIP Client , i.e. statements that refer to normative content in the specificaiton (e.g. ""satisfy all the mandatory (SHALL) statements in Section 123"" or ""Supports the Client-to-Server operations as defined in sections N to M"")",,,,
Technical Advisory Board,TAB-837 ,Self-referencing and confusing statement in KMIP Server conformance clause,Improvement,New,Major,Unresolved,Unassigned,Jacques Durand,17/Mar/14 8:09 PM,,17/Mar/14 8:15 PM,,Key Management Interoperability Protocol Specification Version 1.2,,Public reviews,,1,,,,,Conformance,"Self-referencing and confusing statement in KMIP Server conformance clause: In 12.1: "" A KMIP server implementation SHALL be a conforming KMIP Server."" Is this an attempt to define what is an [KMIP server] implementation ? That should be done independently from the notion of conformance, i.e. in a ""functional"" way, e.g. in a glossary. Then the conformance clause would come in later and say: "" a conforming KMIP Server implementation SHALL satisfy...X, Y Z"". But in any case, the conformance clause should avoid referring to itself (""... SHALL be a conforming KMIP Server."" where the way to ""conform"" is precisely the object of the clause containing that statement.) Or, if you want to reserve the name ""KMIP Server"" exclusively to designate implementations that fulfill this conformance profile, then assuming that you have previously defined a notion of ""Key management Server "" (actually used a lot in the specification narrative, but undefined), you could say as a general introduction to the KMIP Server conformance profile: ""In order to qualify as a KMIP Server , a Key management Server implementation SHALL satisfy X, Y Z"". Where X, Y, Z are the actual meat of the conformance clause for KMIP Server, i.e. statements that refer to normative content in the specificaiton (e.g. ""satisfy all the mandatory (SHALL) statements in Section 123"" or ""Supports the Server-to-Client operations as defined in sections 4.n to 4.m"")",,,,
Technical Advisory Board,TAB-836 ,"Baseline Server /Client conformance amiss, while too much reliance on externally defined ""Profiles"" conformance",Improvement,New,Major,Unresolved,Unassigned,Jacques Durand,17/Mar/14 7:26 PM,,17/Mar/14 8:17 PM,,Key Management Interoperability Protocol Specification Version 1.2,,Public reviews,,1,,,,,Conformance,"Baseline Server /Client conformance amiss, while too much reliance on externally defined ""Profiles"" conformance: In 12.1: ""An implementation is a conforming KMIP Server if the implementation meets the conditions specified in one or more server profiles specified in [KMIP-Prof]."" I was expecting a notion of ""Server"" conformance independent from Profiles: There are many normative statement is this document that seem to apply regardless of profiles. But they donâ??t seem to be referred to or used in the conformance clause? They should be. There is too much reliance on external documents (â??profilesâ??) in defining conformance to THIS specification. For example, why arenâ??t the Baseline Server and the Baseline Client defined in this spec? Instead they are defined in the [KMIP-Prof] spec which abundantly (and exclusively) refers to the present specification for defining these: too much circularity here... Also: What is referred here (KMIP-Prof) has merely WD status.It is not even part of the set of CSDs. These server ""profiles"" should at least be named explicitly here. Same for Client conformance.",,,,
Technical Advisory Board,TAB-835 ,Server and Client undefined,Improvement,New,Major,Unresolved,Unassigned,Jacques Durand,17/Mar/14 7:12 PM,,17/Mar/14 7:12 PM,,Key Management Interoperability Protocol Specification Version 1.2,,Public reviews,,1,,,,,Conformance,"Section 12 Conformance: ""KMIP Server and Client implementation"" These are not defined anywhere in this document. There should be a functional definition of these types of implementation. Ideally in a glossary.",,,,
Technical Advisory Board,TAB-783 ,Link Redirects - 14,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,24/Feb/14 9:24 AM,,24/Feb/14 9:24 AM,,Key Management Interoperability Protocol Specification Version 1.2,,Public reviews,,0,,,,,Style,"The link checker at: http://validator.w3.org/checklink reports 14 redirects of links in this draft as follows: ***** Line: 4957 http://www.rsa.com/rsalabs/node.asp?id=2129 redirected to http://www.emc.com/domains/rsa/index.htm?id=2129 Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 3545 http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip redirected to https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 3424 http://www.emc.com/ redirected to http://www.emc.com/index.htm Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 4944 http://www.rsa.com/rsalabs/node.asp?id=2125 redirected to http://www.emc.com/domains/rsa/index.htm?id=2125 Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 5233 http://www.itu.int/rec/recommendation.asp?lang=en&parent=T-REC-X.509-200811-1 redirected to http://www.itu.int/rec/T-REC-X.509-200811-1/en Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 4967 http://www.rsa.com/rsalabs/node.asp?id=2132 redirected to http://www.emc.com/domains/rsa/index.htm?id=2132 Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Lines: 3416, 3548 http://www.oasis-open.org/committees/kmip/ redirected to https://www.oasis-open.org/committees/kmip/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 3642 http://www.oasis-open.org/ redirected to https://www.oasis-open.org/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 3647 http://www.oasis-open.org/policies-guidelines/trademark redirected to https://www.oasis-open.org/policies-guidelines/trademark Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 4962 http://www.rsa.com/rsalabs/node.asp?id=2130 redirected to http://www.emc.com/domains/rsa/index.htm?id=2130 Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 3429 http://www.netapp.com/ redirected to http://www.netapp.com/us/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 3553 http://www.oasis-open.org/committees/kmip/ipr.php redirected to https://www.oasis-open.org/committees/kmip/ipr.php Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 3586 http://www.oasis-open.org/policies-guidelines/ipr redirected to https://www.oasis-open.org/policies-guidelines/ipr Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 4951 http://www.rsa.com/rsalabs/node.asp?id=2127 redirected to http://www.emc.com/domains/rsa/index.htm?id=2127 Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. *****",,,Update all redirects to their current links.,
Technical Advisory Board,TAB-782 ,Broken HTML link,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,24/Feb/14 9:21 AM,,24/Feb/14 9:21 AM,,Key Management Interoperability Protocol Specification Version 1.2,,Public reviews,,0,,,,,Style,"Appendix F. List of Figures and Tables reads in part: Figure 1: Cryptographic Object States and Transitions, but the tricky bit is the unseen link which reads: ***** file:///C:%5CUsers%5CPaul%20Knight%5CDocuments%5COASIS-TC%5CKMIP%5Cv1.2%5Ckmip-spec-v1.2%5Ccsd01%5Cpaul3a%5Ckmip-spec-v1.2-csd01.doc#_Toc374104146 ***** The link checker skips local references but this is clearly broken with regard to the draft. It should point to figure 1 in the draft.",,,"Replace the present link under ""Figure 1: Cryptographic Object States and Transitions"" with the correct link to Figure 1 in the document.",
Technical Advisory Board,TAB-781 ,Broken Normative Reference Link,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,24/Feb/14 9:12 AM,,24/Feb/14 9:12 AM,,Key Management Interoperability Protocol Specification Version 1.2,,Public reviews,,0,,,,,References,"1.2 Normative References reads in part: ***** [SP800-57-1] E. Barker, W. Barker, W. Burr, W. Polk, and M. Smid, Recommendations for Key Management - Part 1: General (Revision 3), NIST Special Publication 800-57 Part 1 Revision 3, July 2012, http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-part1-rev3_general.pdf. ***** The link checker at: http://validator.w3.org/checklink reports: ***** Line: 5212 http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-part1-rev3_general.pdf Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. *****",,,Replace the link for SP800-57-1.,
Technical Advisory Board,TAB-780 ,Broken Normative Reference link,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,24/Feb/14 9:09 AM,,24/Feb/14 9:09 AM,,Key Management Interoperability Protocol Specification Version 1.2,,Public reviews,,0,,,,,References,"1.2 Normative References reads in part: ***** [FIPS186-4] Digital Signature Standard (DSS), FIPS PUB 186-4, July 2013, http://csrc.nist.gov/publications/FIPS/NIST.FIPS.186-4.pdf. ***** The link checker at: http://validator.w3.org/checklink reports: ***** Line: 4904 http://csrc.nist.gov/publications/FIPS/NIST.FIPS.186-4.pdf Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. error *****",,,Correct the link for FIPS186-4.,
Technical Advisory Board,TAB-779 ,HTML redirects - 8,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,23/Feb/14 8:14 PM,,23/Feb/14 8:14 PM,,Key Management Interoperability Protocol Specification Version 1.2,,Public reviews,,0,,,,,Style,"The link checker at http://validator.w3.org/checklink reports 8 redirects in links for this draft as follows: ***** warning Line: 706 http://www.oracle.com/ redirected to http://www.oracle.com/index.html Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Lines: 699, 746 http://www.oasis-open.org/committees/xacml/ redirected to https://www.oasis-open.org/committees/xacml/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 751 http://www.oasis-open.org/committees/xacml/ipr.php redirected to https://www.oasis-open.org/committees/xacml/ipr.php Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 743 http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=xacml redirected to https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=xacml Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 837 http://www.oasis-open.org/ redirected to https://www.oasis-open.org/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 842 http://www.oasis-open.org/policies-guidelines/trademark redirected to https://www.oasis-open.org/policies-guidelines/trademark Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 715 http://www.axiomatics.com/ redirected to https://www.axiomatics.com/ Status: 303 -> 200 OK warning Line: 781 http://www.oasis-open.org/policies-guidelines/ipr redirected to https://www.oasis-open.org/policies-guidelines/ipr Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. *****",,,Update the links to cure the redirects.,
Generated at Fri Mar 21 13:18:55 UTC 2014 by Patrick Durusau using JIRA 6.1.1#6155-sha1:7188aeec9a6b57d61ea04c52f235f15f55c105e2.,,,,,,,,,,,,,,,,,,,,,,,,,,,
,,,,,,,,,,,,,,,,,,,,,,,,,,, OASIS Technical Committees Issue Tracker ,,,,,,,,,,,,,,,,,,,,,,,,,,, Displaying 20 issues at 21/Mar/14 9:32 AM.,,,,,,,,,,,,,,,,,,,,,,,,,,, Project,Key,Summary,Issue Type,Status,Priority,Resolution,Assignee,Reporter,Created,Last Viewed,Updated,Resolved,Affects Version/s,Fix Version/s,Component/s,Due Date,Watchers,Images,Work Ratio,Sub-Tasks,Linked Issues,Environment,Description,Security Level,Labels,Proposal,Resolution Technical Advisory Board,TAB-980 ,References from Test Cases,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,21/Mar/14 8:42 AM,21/Mar/14 9:32 AM,21/Mar/14 8:42 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Technical,"Example from KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0 3.1 reads: ""This section documents the test cases that a client or server conformant to the Symmetric Key Foundry (FIPS140) Profile SHALL support under KMIP Specification 1.0."" 3.1.6 SKFF-M-6-10 reads in part: ***** Create, Locate, Get, Destroy, Locate AES-192 ***** One assumes that ""Create"" refers to some part of KMIP Specification 1.0 and refers to at least one of the test cases that follows in that section. Create should be followed by [KMIP-PROF-1_0:(section number) (title) and then followed by its test case in this profile. Otherwise which test case is for which part of KMIP-PROF-1_0 isn't clear. This is just one example. All of the test cases should have specific references of the form mentioned (to facilitate automated checking) and have the test cases separated from each other.",,,"Create separate references for each reference to a version of KMIP that consist of your key, a section number and the title of the section number, to facilitate automated checking of the references.", Technical Advisory Board,TAB-979 ,Test Case Identification,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,21/Mar/14 8:38 AM,21/Mar/14 8:38 AM,21/Mar/14 8:38 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Structure,"Example from KMIP Tape Library Profile Version 1.0 ***** The Tape Library constructs an identifier string based on the method in 2.3, then requests the server to Locate that string via ASI. A Get is then requested based on the key's unique identifier. The Tape Library MAY update attributes associated with the Symmetric Key Managed Object. The following test case shows extensive use of custom attributes. Custom attributes are not required if the Application Name is unique within the Application Namespace. An implementation may also use custom attributes for vendor-unique purposes, or to improve usability. The test case destroys the key created in the previous test case to clean up after the test. Tape Library implementations MAY not perform this step. ***** This statement is followed by test cases that are not separated from each other or have the ""custom attributes"" or goal of each test described. Every test case should be separated from every other test cases and have the conditions and goal of the test described in prose. This applies to all the test cases in the listed versions.",,,Separate each test case from others and describe its inputs/outputs and/or conditions in prose., Technical Advisory Board,TAB-975 ,Poor formatting of test case content,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 12:07 PM,20/Mar/14 6:34 PM,20/Mar/14 12:07 PM,,KMIP Opaque Managed Object Store Profile Version 1.0,,,,1,,,,,Style,"Material in the <OpaqueDataValue> element attribute ""value"" scrolls off screen a considerable distance and instead a large chunk of whitespace is displayed. The HTML version is consistent with the others (so far as I can tell) but the formatting needs to be corrected. In the HTML see: 3.4.1 Test case line starting at: 0024 3.5.1 Test case line starting at: 0024 3.6.1 Test case line starting at: 0024",,,Correct formatting of the HTML version to approximate the Word and PDF versions., Technical Advisory Board,TAB-974 ,Hanging Paragraphs + Bad subsections,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 11:58 AM,20/Mar/14 6:37 PM,20/Mar/14 11:58 AM,,KMIP Opaque Managed Object Store Profile Version 1.0,,,,1,,,,,Style,"Sections 1 and 1.1 illustrate the issue with hanging paragraphs. If I say see Section 1, do I mean the paragraphs following section 1 or do I mean that + 1.1 - 1.3? Hanging paragraphs in this draft are: 1, 1.1 2, 2.1 3, 3.1 3.1, 3.1.1 3.2, 3.2.1 3.3, 3.3.1 3.4, 3.4.1 3.5, 3.5.1 3.6, 3.6.1 4, 4.1 4.1, 4.1.1 The following are improper subsections. That is there is 3.2.1 but no 3.2.2. combine 3.2 and 3.2.1 into a single section. Solves the hanging paragraph issue and the improper subsectioning. 3.1, 3.1.1 3.2, 3.2.1 3.3, 3.3.1 3.4, 3.4.1 3.5, 3.5.1 3.6, 3.6.1",,,Re-section the draft to remove hanging paragraphs, Technical Advisory Board,TAB-968 ,Repetition of Appendix B?,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 10:55 AM,20/Mar/14 10:55 AM,20/Mar/14 10:55 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"Unless I am mistaken, Appendix B. KMIP Specification Cross Reference appears in all of the profiles. At the same time, all of the profiles make reference to KMIP-SPEC, where Appendix B also occurs. That is in order to use any of the profiles, the reader must also have a copy of KMIP-SPEC. In the PDF versions, that adds another five (5) pages to each profile. Or a total of 45 pages of duplicated materials, which if printed, are likely to be discarded.",,,Suggest deletion of Appendix B in all profiles in favor of the mapping which already appears in KMIP-SPEC., Technical Advisory Board,TAB-966 ,Test Cases - violation of DRY?,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 10:15 AM,21/Mar/14 9:12 AM,20/Mar/14 10:22 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"After reading over my prior comments on test cases and reviewing the test cases in the drafts, it occurred to me that the test cases follow what is already a normative statement of requirements for each profile. Yes? Taking Tape Profile 1.0 as an example, 2 Tape Library Profile defines all the normative requirements for that profile. Yes? That is to say that if I do everything in 2 Tape Library Profile, I will be conforming to that profile of KMIP-SPEC. Yes? If that's the case, the the test cases violate DRY - Don't Repeat Yourself and are unnecessary. You have said all you need to say. Why say more? I still think the test cases are valuable but would put them in a non-normative document.",,,"Move all test cases to a non-normative document and allow normative requirements to stand by themselves, without repetition.", Technical Advisory Board,TAB-962 ,Suggestion for a normative interpretation of Test Cases,Improvement,New,Major,Unresolved,Unassigned,Jacques Durand,19/Mar/14 9:37 PM,,19/Mar/14 10:33 PM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0",,Public reviews,,1,,,,,Normative,"Suggestion for a normative interpretation of Test Cases: Since many KMIP profiles are specified in terms of ""test cases"", a normative interpretation should be given for these test cases. This could be done as a set of rules, that determine what the ""response"" should look like based on the ""Request"" message (assuming the implementation under test, i.e. the conformance target, is the one producing the response). These rules would be generic as much as possible (apply to all test cases in a profile at least). These rules can look like:. 1. Schema rule(s): when receiving a Request that satisfies [XML?] schema X, the implementation MUST send back a response that satisfies [XML?] schema Y. 2. Error rule(s): when receiving a Request that is incorrect (for various reasons) , the implementation MUST (or SHOULD?) send back a response that is of the form.... 3. Processing scope rules: they state what kind of Request content variations (both in terms of atomic values and optional elements) an implementation MUST accept (i.e. process and return something else than an Error). 4. Content dependency rules: these would capture several of the ""test case variation"" response cases, but establish a clear dependency rule with similar or related content in the Request.(i.e. how the Request content determines the Response content) 5. Independent variation rules: hese would restate several of the ""test case variation"" cases, that are independent from the Request content or the dependency of which is not easily expressed nor obvious. But maybe a range of resulting values can be stated. Such normative rules would be part of the specification body, but referred by the COnformance clause. With such rules, the Conformance Clause (for related implementation ) can say: ""[KMIP server] when receiving a Request matching any of the Mandatory test Cases (where ""matching"" allows variations as stated by rules X,Y,Z) , the [server] MUST generate a Response that satisfies the rules 1,2,3,4,5. when applied to the test case response."" instead of: ""support all Mandatory Test Cases (3.1and 3.2 and 3.3), for each supported protocol version (major and minor), returning results in accordance with the test cases."" Note you can then remove the confusingly vague statement: ""Note: the values for the returned items and the custom attributes are illustrative. Actual values from a real client system will vary. "" As this variability would be now defined by normative ""rules"". You can then state that all these test cases (along with their usage or variation rules) are normative content.",,,, Technical Advisory Board,TAB-946 ,Conformance based on Test Cases,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 8:04 PM,19/Mar/14 8:04 PM,19/Mar/14 8:04 PM,,KMIP Opaque Managed Object Store Profile Version 1.0,,,,1,,,,,Normative,"Test cases are referenced in the conformance clauses, but only the test can be normative. As the draft states, the results may vary from those shown. If the results may vary, an implementer can't judge if they have properly pass the test case required for conformance.",,,"As I suggest in another comment, all test cases should be moved to Key Management Interoperability Protocol Test Cases Version 1.2 (or some other non-normative document) and reform conformance clauses to not depend on test cases.", Technical Advisory Board,TAB-945 ,Test Cases - Structure,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 8:03 PM,19/Mar/14 8:18 PM,19/Mar/14 8:18 PM,,KMIP Opaque Managed Object Store Profile Version 1.0,,,,1,,,,,Normative,"From Key Management Interoperability Protocol Test Cases Version 1.2 1 Introduction reads: ""The purpose of this document is to describe test cases to demonstrate the Key Management Interoperability Protocol (KMIP) [KMIP-SPEC-1_2], [KMIP-SPEC-1_1], and [KMIP-SPEC-1_0]. The test cases illustrate that the concepts within the protocol are sound and how the protocol may be used when implementing KMIP in applications. These test cases are not intended to fully test an implementation of KMIP. There are test cases for v1.0, v1.1 and v1.2 of the protocol."" And 2 KMIP Test Cases reads in part: ""The test cases show one possible way to construct the messages, and the messages shown are not necessarily the only conformant constructions as many items within KMIP are optional and server behavior depends on the server's policy. Support for a test case is predicated on a server matching the test case assumptions and the behavior shown in the request-response pairs."" If that is true for KMIP 1.2, it is certainly also true for KMIP Opaque Managed Object Store Profile. A more useful location for the test cases would be in Key Management Interoperability Protocol Test Cases Version 1.2 and for the conformance clauses of Opaque Managed Object Store to be written without reference to test cases. Which as noted above, doesn't really test all of a standard.",,,"Move test cases to Key Management Interoperability Protocol Test Cases Version 1.2, reform conformance clauses to not depend on test cases.", Technical Advisory Board,TAB-944 ,Test Cases - No reference for type constraints,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 8:02 PM,19/Mar/14 8:02 PM,19/Mar/14 8:02 PM,,KMIP Opaque Managed Object Store Profile Version 1.0,,,,1,,,,,Technical,"The test cases that appear in XML markup contain attribute value restrictions. However, there is no normative citation of value definitions nor is there a schema to enforce those definitions, if given.",,,Normative citation of XML Schema Part 2 plus an XML schema for the test cases as defined are required at a minimum. Usefulness for users also requires the test cases in machine readable XML format., Technical Advisory Board,TAB-943 ,Test Cases - Normative vs. Non-Normative,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 8:01 PM,19/Mar/14 8:01 PM,19/Mar/14 8:01 PM,,KMIP Opaque Managed Object Store Profile Version 1.0,,,,1,,,,,Normative,"The note in 3 reads: Note: the values for the returned items and the custom attributes are illustrative. Actual values from a real client system will vary. If the test cases are normative, then the responses are not and should be so marked. If the test cases are non-normative, then all should be marked as non-normative.",,,Mark all or part of use cases as non-normative as appropriate, Technical Advisory Board,TAB-942 ,"Notes need to be typographically distinct, non-normative",Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 8:00 PM,19/Mar/14 8:00 PM,19/Mar/14 8:00 PM,,KMIP Opaque Managed Object Store Profile Version 1.0,,,,1,,,,,Normative,3 Opaque Managed Object Store Profile - Test Cases Note: the values for the returned items and the custom attributes are illustrative. Actual values from a real client system will vary. The note is not typographically distinct from other text.,,,Make notes typographically distinct and declare to be non-normative., Technical Advisory Board,TAB-941 ,Normative versus Non-Normative Text,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 7:57 PM,19/Mar/14 7:57 PM,19/Mar/14 7:57 PM,,KMIP Opaque Managed Object Store Profile Version 1.0,,,,1,,,,,Normative,"No statement of normative versus non-normative text. Which leads to failure to distinguish normative text from non-normative text. For example, is Appendix B normative?",,,"Mark sections as normative vs. non-normative or state at the outset that introductions, notes, examples, etc. are all non-normative.", Technical Advisory Board,TAB-934 ,Citations without section numbers,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 5:30 PM,20/Mar/14 10:03 AM,20/Mar/14 10:02 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, Key Management Interoperability Protocol Usage Guide Version 1.2, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"Just by way of example, 2.2 Suite B minLOS_128 (KMIP Suite B Profile Version 1.0) reads in part: ***** SHALL conform to the Baseline Server profile in [KMIP-PROF] and [KMIP-SPEC] and SHALL support the following Objects [KMIP-SPEC] Certificate [KMIP-SPEC] Symmetric Key [KMIP-SPEC] Public Key [KMIP-SPEC] Private Key [KMIP-SPEC] ***** Citations should include specific section numbers and titles in the cited document. I say that for two reasons: 1) The expert reader (members of this TC) are more likely to recognize an incorrect section citation by its title than by either [KMIP-SPEC] or [KMIP-SPEC:2.2.3]. Say for example if the citation were incorrect and read: [KMIP-SPEC:2.2.7], even an expert reader would be hard pressed to spot that error. On the other hand, if it read: ""Public Key [KMIP-SPEC:2.2.7 Secret Data]"" a TC member would know that wasn't the correct citation. 2) Assuming that all KMIP references between parts of this specification are written KMIP-(key):(number) (title), then it will be possible to automatically validate all of those references. For example, for KMIP-SPEC (the main document), all the section numbers and titles could be automatically extracted and then applied to a document with references to the KMIP-SPEC. By ""applied"" I mean compared to the citations in the text. Where it matches, nothing happens, but, where for whatever reason there is a KMIP cite that does not match, it is highlighted in red (for example). Proofing all the citations, at least to KMIP work, becomes a process of simply scrolling through the document looking for highlights. That won't help if the section citation is correct but substantively incorrect but only a human reader could catch that sort of error. The scripting, assuming reformation of the citations, would not take long and the actual running of the script against all the files would take less than 10 minutes. If not less. I note the work that went into Appendix B and if that effort is to be made on behalf of old users, it is much more necessary for new users of your latest work.",,,"Insert section numbers and titles for all citations of references, thus c. Public Key [KMIP-SPEC:2.2.3 Public Key] noting that ""public key"" appears all over KMIP-SPEC. The section reference makes it clear what is being referenced.", Technical Advisory Board,TAB-922 ,"What it means to ""support a Mandatory Test Case"" is not clearly & normatively defined",Improvement,New,Major,Unresolved,Unassigned,Jacques Durand,19/Mar/14 1:21 AM,,19/Mar/14 9:44 PM,,KMIP Opaque Managed Object Store Profile Version 1.0,,Public reviews,,1,,,,,Normative,"What it means to ""support a Mandatory Test Case"" is not clearly & normatively defined. Similar comment made in other documents, about the necessity to define what a ""normative interpretation"" of these test cases is - i.e. what it means to ""support a Mandatory Test Case"" . The ""Permitted Test Case Variations"" should be part of that normative interpretation, but there is more to it. A normative interpretation defined as part of the specification is needed, because these Test Cases are used in a conformance clause and therefore are parts of the specification too,as opposed to being part of a test suite outside the specification. They are used as part of the definition of conformance, not just part of of a test suite to *verify* if an implementation adheres to a conformance definition otherwise self-sufficient and independent from any test case by itself. This is not quite the same thing. See comment TAB-962 for a suggestion on how to give normative meaning to test Cases in the profile specification.",,,, Technical Advisory Board,TAB-921 ,COnformance clause should be per conformance target,Improvement,New,Major,Unresolved,Unassigned,Jacques Durand,19/Mar/14 1:18 AM,,19/Mar/14 1:18 AM,,KMIP Opaque Managed Object Store Profile Version 1.0,,Public reviews,,1,,,,,Conformance,"There should be two different conformance clauses for two conformance targets as different as CLient & Server, instead of a single clause that expresses the same requirements regardless of the type of implementation.",,,, Technical Advisory Board,TAB-920 ,Confusing redundancy in conformance statements outside conformance clause:,Bug,New,Major,Unresolved,Unassigned,Jacques Durand,18/Mar/14 6:33 PM,,18/Mar/14 6:33 PM,,KMIP Opaque Managed Object Store Profile Version 1.0,,Public reviews,,1,,,,,Structure,"Confusing redundancy in conformance statements outside conformance clause: ""section 4 ""Conformance"" is clearly redundant with : sections 2.1 and 2.2 Both pretend to be a conformance clause for Client and Server. Sections 2 should merge into the Conformance section: there should not be any conformance statement outside the conformance section.",,,, Technical Advisory Board,TAB-909 ,Duplicated Reference,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:46 AM,,18/Mar/14 11:46 AM,,KMIP Opaque Managed Object Store Profile Version 1.0,,,,1,,,,,References,1.2 Normative References has two citations to RFC2119.,,,Delete one (1) reference to RFC2119, Technical Advisory Board,TAB-908 ,Obsoleted Reference,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:46 AM,,18/Mar/14 11:46 AM,,KMIP Opaque Managed Object Store Profile Version 1.0,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC2246] T. Dierks and C. Allen, The TLS Protocol, Version 1.0, IETF RFC 2246, Jan 1999, http://www.ietf.org/rfc/rfc2246.txt The RFC editor's list at: http://www.rfc-editor.org/in-notes/rfc-ref.txt shows RFC2246 as superseded by RFC4346, which was itself superseded by RFC5246, which should be cited as: [RFC5246] Dierks, T. and E. Rescorla, ""The Transport Layer Security (TLS) Protocol Version 1.2"", RFC 5246, August 2008. http://www.ietf.org/rfc/rfc5246.txt Superseded references should not be cited in current work. Suggest updating the reference. On the other hand, since RFC2246 is not cited in this draft, you probably should just delete it.",,,Update or delete reference., Technical Advisory Board,TAB-796 ,Link Redirects 9,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,25/Feb/14 9:57 AM,,25/Feb/14 9:57 AM,,KMIP Opaque Managed Object Store Profile Version 1.0,,Public reviews,,0,,,,,Style,"The link checker at: http://validator.w3.org/checklink reports 9 link redirects as follows: ***** warning Line: 961 http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip redirected to https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 907 http://www.emc.com/ redirected to http://www.emc.com/index.htm Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 921 http://www.thales-esecurity.com/ redirected to https://www.thales-esecurity.com/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1056 http://www.oasis-open.org/ redirected to https://www.oasis-open.org/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Lines: 899, 964 http://www.oasis-open.org/committees/kmip/ redirected to https://www.oasis-open.org/committees/kmip/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1061 http://www.oasis-open.org/policies-guidelines/trademark redirected to https://www.oasis-open.org/policies-guidelines/trademark Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 969 http://www.oasis-open.org/committees/kmip/ipr.php redirected to https://www.oasis-open.org/committees/kmip/ipr.php Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 912 http://www.netapp.com/ redirected to http://www.netapp.com/us/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1000 http://www.oasis-open.org/policies-guidelines/ipr redirected to https://www.oasis-open.org/policies-guidelines/ipr Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. *****",,,Update the links to their exact URLs., Generated at Fri Mar 21 13:32:47 UTC 2014 by Patrick Durusau using JIRA 6.1.1#6155-sha1:7188aeec9a6b57d61ea04c52f235f15f55c105e2.,,,,,,,,,,,,,,,,,,,,,,,,,,,
,,,,,,,,,,,,,,,,,,,,,,,,,,, OASIS Technical Committees Issue Tracker ,,,,,,,,,,,,,,,,,,,,,,,,,,, Displaying 20 issues at 21/Mar/14 9:30 AM.,,,,,,,,,,,,,,,,,,,,,,,,,,, Project,Key,Summary,Issue Type,Status,Priority,Resolution,Assignee,Reporter,Created,Last Viewed,Updated,Resolved,Affects Version/s,Fix Version/s,Component/s,Due Date,Watchers,Images,Work Ratio,Sub-Tasks,Linked Issues,Environment,Description,Security Level,Labels,Proposal,Resolution Technical Advisory Board,TAB-980 ,References from Test Cases,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,21/Mar/14 8:42 AM,21/Mar/14 9:30 AM,21/Mar/14 8:42 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Technical,"Example from KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0 3.1 reads: ""This section documents the test cases that a client or server conformant to the Symmetric Key Foundry (FIPS140) Profile SHALL support under KMIP Specification 1.0."" 3.1.6 SKFF-M-6-10 reads in part: ***** Create, Locate, Get, Destroy, Locate AES-192 ***** One assumes that ""Create"" refers to some part of KMIP Specification 1.0 and refers to at least one of the test cases that follows in that section. Create should be followed by [KMIP-PROF-1_0:(section number) (title) and then followed by its test case in this profile. Otherwise which test case is for which part of KMIP-PROF-1_0 isn't clear. This is just one example. All of the test cases should have specific references of the form mentioned (to facilitate automated checking) and have the test cases separated from each other.",,,"Create separate references for each reference to a version of KMIP that consist of your key, a section number and the title of the section number, to facilitate automated checking of the references.", Technical Advisory Board,TAB-979 ,Test Case Identification,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,21/Mar/14 8:38 AM,21/Mar/14 8:38 AM,21/Mar/14 8:38 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Structure,"Example from KMIP Tape Library Profile Version 1.0 ***** The Tape Library constructs an identifier string based on the method in 2.3, then requests the server to Locate that string via ASI. A Get is then requested based on the key's unique identifier. The Tape Library MAY update attributes associated with the Symmetric Key Managed Object. The following test case shows extensive use of custom attributes. Custom attributes are not required if the Application Name is unique within the Application Namespace. An implementation may also use custom attributes for vendor-unique purposes, or to improve usability. The test case destroys the key created in the previous test case to clean up after the test. Tape Library implementations MAY not perform this step. ***** This statement is followed by test cases that are not separated from each other or have the ""custom attributes"" or goal of each test described. Every test case should be separated from every other test cases and have the conditions and goal of the test described in prose. This applies to all the test cases in the listed versions.",,,Separate each test case from others and describe its inputs/outputs and/or conditions in prose., Technical Advisory Board,TAB-973 ,Hanging Paragraphs (5),Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 11:50 AM,20/Mar/14 11:50 AM,20/Mar/14 11:50 AM,,KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0,,,,1,,,,,Style,"Sections 1 and 1.1 illustrate the issue with hanging paragraphs. If I say see Section 1, do I mean the paragraphs following section 1 or do I mean that + 1.1 - 1.3? Hanging paragraphs in this draft are: 1, 1.1 2, 2.1 3, 3.1 3.1, 3.1.1 4.2, 4.2.1",,,Re-section the draft to remove hanging paragraphs, Technical Advisory Board,TAB-968 ,Repetition of Appendix B?,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 10:55 AM,20/Mar/14 10:55 AM,20/Mar/14 10:55 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"Unless I am mistaken, Appendix B. KMIP Specification Cross Reference appears in all of the profiles. At the same time, all of the profiles make reference to KMIP-SPEC, where Appendix B also occurs. That is in order to use any of the profiles, the reader must also have a copy of KMIP-SPEC. In the PDF versions, that adds another five (5) pages to each profile. Or a total of 45 pages of duplicated materials, which if printed, are likely to be discarded.",,,Suggest deletion of Appendix B in all profiles in favor of the mapping which already appears in KMIP-SPEC., Technical Advisory Board,TAB-966 ,Test Cases - violation of DRY?,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 10:15 AM,21/Mar/14 9:12 AM,20/Mar/14 10:22 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"After reading over my prior comments on test cases and reviewing the test cases in the drafts, it occurred to me that the test cases follow what is already a normative statement of requirements for each profile. Yes? Taking Tape Profile 1.0 as an example, 2 Tape Library Profile defines all the normative requirements for that profile. Yes? That is to say that if I do everything in 2 Tape Library Profile, I will be conforming to that profile of KMIP-SPEC. Yes? If that's the case, the the test cases violate DRY - Don't Repeat Yourself and are unnecessary. You have said all you need to say. Why say more? I still think the test cases are valuable but would put them in a non-normative document.",,,"Move all test cases to a non-normative document and allow normative requirements to stand by themselves, without repetition.", Technical Advisory Board,TAB-962 ,Suggestion for a normative interpretation of Test Cases,Improvement,New,Major,Unresolved,Unassigned,Jacques Durand,19/Mar/14 9:37 PM,,19/Mar/14 10:33 PM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0",,Public reviews,,1,,,,,Normative,"Suggestion for a normative interpretation of Test Cases: Since many KMIP profiles are specified in terms of ""test cases"", a normative interpretation should be given for these test cases. This could be done as a set of rules, that determine what the ""response"" should look like based on the ""Request"" message (assuming the implementation under test, i.e. the conformance target, is the one producing the response). These rules would be generic as much as possible (apply to all test cases in a profile at least). These rules can look like:. 1. Schema rule(s): when receiving a Request that satisfies [XML?] schema X, the implementation MUST send back a response that satisfies [XML?] schema Y. 2. Error rule(s): when receiving a Request that is incorrect (for various reasons) , the implementation MUST (or SHOULD?) send back a response that is of the form.... 3. Processing scope rules: they state what kind of Request content variations (both in terms of atomic values and optional elements) an implementation MUST accept (i.e. process and return something else than an Error). 4. Content dependency rules: these would capture several of the ""test case variation"" response cases, but establish a clear dependency rule with similar or related content in the Request.(i.e. how the Request content determines the Response content) 5. Independent variation rules: hese would restate several of the ""test case variation"" cases, that are independent from the Request content or the dependency of which is not easily expressed nor obvious. But maybe a range of resulting values can be stated. Such normative rules would be part of the specification body, but referred by the COnformance clause. With such rules, the Conformance Clause (for related implementation ) can say: ""[KMIP server] when receiving a Request matching any of the Mandatory test Cases (where ""matching"" allows variations as stated by rules X,Y,Z) , the [server] MUST generate a Response that satisfies the rules 1,2,3,4,5. when applied to the test case response."" instead of: ""support all Mandatory Test Cases (3.1and 3.2 and 3.3), for each supported protocol version (major and minor), returning results in accordance with the test cases."" Note you can then remove the confusingly vague statement: ""Note: the values for the returned items and the custom attributes are illustrative. Actual values from a real client system will vary. "" As this variability would be now defined by normative ""rules"". You can then state that all these test cases (along with their usage or variation rules) are normative content.",,,, Technical Advisory Board,TAB-940 ,Conformance based on Test Cases,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 7:54 PM,19/Mar/14 7:55 PM,19/Mar/14 7:54 PM,,KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0,,,,1,,,,,Conformance,"Test cases are referenced in the conformance clauses, but only the test can be normative. As the draft states, the results may vary from those shown. If the results may vary, an implementer can't judge if they have properly pass the test case required for conformance.",,,"As I suggest in another comment, all test cases should be moved to Key Management Interoperability Protocol Test Cases Version 1.2 (or some other non-normative document) and reform conformance clauses to not depend on test cases.", Technical Advisory Board,TAB-939 ,Test Cases - Structure,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 7:52 PM,19/Mar/14 8:20 PM,19/Mar/14 8:20 PM,,KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0,,,,1,,,,,Normative,"From Key Management Interoperability Protocol Test Cases Version 1.2 1 Introduction reads: ""The purpose of this document is to describe test cases to demonstrate the Key Management Interoperability Protocol (KMIP) [KMIP-SPEC-1_2], [KMIP-SPEC-1_1], and [KMIP-SPEC-1_0]. The test cases illustrate that the concepts within the protocol are sound and how the protocol may be used when implementing KMIP in applications. These test cases are not intended to fully test an implementation of KMIP. There are test cases for v1.0, v1.1 and v1.2 of the protocol."" And 2 KMIP Test Cases reads in part: ""The test cases show one possible way to construct the messages, and the messages shown are not necessarily the only conformant constructions as many items within KMIP are optional and server behavior depends on the server's policy. Support for a test case is predicated on a server matching the test case assumptions and the behavior shown in the request-response pairs."" If that is true for KMIP 1.2, it is certainly also true for KMIP Storage Array with Self-Encrypting Drives Profile. A more useful location for the test cases would be in Key Management Interoperability Protocol Test Cases Version 1.2 and for the conformance clauses of Storage Array with Self-Encrypting Drives Profile to be written without reference to test cases. Which as noted above, doesn't really test all of a standard.",,,"Move test cases to Key Management Interoperability Protocol Test Cases Version 1.2, reform conformance clauses to not depend on test cases.", Technical Advisory Board,TAB-938 ,Test Cases - No reference for type constraints,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 7:51 PM,19/Mar/14 7:51 PM,19/Mar/14 7:51 PM,,KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0,,,,1,,,,,Technical,"The test cases that appear in XML markup contain attribute value restrictions. However, there is no normative citation of value definitions nor is there a schema to enforce those definitions, if given.",,,Normative citation of XML Schema Part 2 plus an XML schema for the test cases as defined are required at a minimum. Usefulness for users also requires the test cases in machine readable XML format., Technical Advisory Board,TAB-937 ,Test Cases - Normative vs. Non-Normative,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 7:50 PM,21/Mar/14 9:12 AM,19/Mar/14 7:50 PM,,KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0,,,,1,,,,,Normative,"3 Storage Array with Self-Encrypting Drives Test Cases reads in part: ""Note: the values for the returned items and the custom attributes are illustrative. Actual values from a real client system will vary."" If the test cases are normative, then the responses are not and should be so marked. If the test cases are non-normative, then all should be marked as non-normative.",,,Mark all or part of use cases as non-normative as appropriate, Technical Advisory Board,TAB-936 ,"Notes need to be typographically distinct, non-normative",Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 7:48 PM,19/Mar/14 7:57 PM,19/Mar/14 7:48 PM,,KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0,,,,1,,,,,Style,"3 Storage Array with Self-Encrypting Drives Test Cases reads in part: ""Note: the values for the returned items and the custom attributes are illustrative. Actual values from a real client system will vary."" The note is left aligned like other text. ""Note:"" Need to be typographically distinct and are non-normative. Easiest way is to declare all notes as non-normative.",,,Make notes typographically distinct and declare to be non-normative., Technical Advisory Board,TAB-935 ,Normative vs. Non-Normative text,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 7:46 PM,19/Mar/14 7:56 PM,19/Mar/14 7:46 PM,,KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0,,,,1,,,,,Normative,"No statement of normative versus non-normative text. Which leads to failure to distinguish normative text from non-normative text. For example, is Appendix B normative?",,,"Mark sections as normative vs. non-normative or state at the outset that introductions, notes, examples, etc. are all non-normative.", Technical Advisory Board,TAB-934 ,Citations without section numbers,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 5:30 PM,20/Mar/14 10:03 AM,20/Mar/14 10:02 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, Key Management Interoperability Protocol Usage Guide Version 1.2, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"Just by way of example, 2.2 Suite B minLOS_128 (KMIP Suite B Profile Version 1.0) reads in part: ***** SHALL conform to the Baseline Server profile in [KMIP-PROF] and [KMIP-SPEC] and SHALL support the following Objects [KMIP-SPEC] Certificate [KMIP-SPEC] Symmetric Key [KMIP-SPEC] Public Key [KMIP-SPEC] Private Key [KMIP-SPEC] ***** Citations should include specific section numbers and titles in the cited document. I say that for two reasons: 1) The expert reader (members of this TC) are more likely to recognize an incorrect section citation by its title than by either [KMIP-SPEC] or [KMIP-SPEC:2.2.3]. Say for example if the citation were incorrect and read: [KMIP-SPEC:2.2.7], even an expert reader would be hard pressed to spot that error. On the other hand, if it read: ""Public Key [KMIP-SPEC:2.2.7 Secret Data]"" a TC member would know that wasn't the correct citation. 2) Assuming that all KMIP references between parts of this specification are written KMIP-(key):(number) (title), then it will be possible to automatically validate all of those references. For example, for KMIP-SPEC (the main document), all the section numbers and titles could be automatically extracted and then applied to a document with references to the KMIP-SPEC. By ""applied"" I mean compared to the citations in the text. Where it matches, nothing happens, but, where for whatever reason there is a KMIP cite that does not match, it is highlighted in red (for example). Proofing all the citations, at least to KMIP work, becomes a process of simply scrolling through the document looking for highlights. That won't help if the section citation is correct but substantively incorrect but only a human reader could catch that sort of error. The scripting, assuming reformation of the citations, would not take long and the actual running of the script against all the files would take less than 10 minutes. If not less. I note the work that went into Appendix B and if that effort is to be made on behalf of old users, it is much more necessary for new users of your latest work.",,,"Insert section numbers and titles for all citations of references, thus c. Public Key [KMIP-SPEC:2.2.3 Public Key] noting that ""public key"" appears all over KMIP-SPEC. The section reference makes it clear what is being referenced.", Technical Advisory Board,TAB-925 ,Conformance clause should be per conformance target,Improvement,New,Major,Unresolved,Unassigned,Jacques Durand,19/Mar/14 1:29 AM,,19/Mar/14 1:29 AM,,KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0,,Public reviews,,1,,,,,Conformance,"There should be two different conformance clauses for two conformance targets as different as CLient & Server, instead of a single clause that expresses the same requirements regardless of the type of implementation.",,,, Technical Advisory Board,TAB-924 ,"What it means to ""support a Mandatory Test Case"" is not clearly & normatively defined",Improvement,New,Major,Unresolved,Unassigned,Jacques Durand,19/Mar/14 1:28 AM,,19/Mar/14 9:43 PM,,KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0,,Public reviews,,1,,,,,Normative,"Similar comment made in other documents, about the necessity to define what a ""normative interpretation"" of these test cases is - i.e. what it means to ""support a Mandatory Test Case"" . The ""Permitted Test Case Variations"" should be part of that normative interpretation, but there is more to it. A normative interpretation (of Test Cases) defined as part of the specification is needed, because these Test Cases are used in a conformance clause and therefore are parts of the specification too, as opposed to being part of a test suite outside the specification. They are used as part of the definition of conformance, not just part of of a test suite to *verify* if an implementation adheres to a conformance definition otherwise self-sufficient and independent from any test case by itself. This is not quite the same thing. See comment TAB-962 for a suggestion on how to give normative meaning to test Cases in the profile specification.",,,, Technical Advisory Board,TAB-923 ,Confusing redundancy in conformance statements outside conformance clause,Improvement,New,Major,Unresolved,Unassigned,Jacques Durand,19/Mar/14 1:25 AM,,19/Mar/14 1:25 AM,,KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0,,Public reviews,,1,,,,,Structure,"Confusing redundancy in conformance statements outside conformance clause: Similar comment made in other documents, about some conformance statements made outside the COnformance section. ""section 2.1 and 2.2"" are clearly redundant with : ""section 4 ""Conformance"". Both pretend to be a conformance clause for Client and Server. Sections 2 should merge into the Conformance section: there should not be any conformance statement outside the conformance section.",,,, Technical Advisory Board,TAB-907 ,Obsoleted Reference,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:45 AM,,18/Mar/14 11:45 AM,,KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC2246] T. Dierks and C. Allen, The TLS Protocol, Version 1.0, IETF RFC 2246, Jan 1999, http://www.ietf.org/rfc/rfc2246.txt The RFC editor's list at: http://www.rfc-editor.org/in-notes/rfc-ref.txt shows RFC2246 as superseded by RFC4346, which was itself superseded by RFC5246, which should be cited as: [RFC5246] Dierks, T. and E. Rescorla, ""The Transport Layer Security (TLS) Protocol Version 1.2"", RFC 5246, August 2008. http://www.ietf.org/rfc/rfc5246.txt Superseded references should not be cited in current work. Suggest updating the reference. On the other hand, since RFC2246 is not cited in this draft, you probably should just delete it.",,,Update or delete reference., Technical Advisory Board,TAB-795 ,Broken HTML Links,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,25/Feb/14 9:54 AM,,25/Feb/14 9:54 AM,,KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0,,Public reviews,,0,,,,,References,"1.3 Non-Normative References reads in part: ***** [KMIP-UG-1_0] Key Management Interoperability Protocol Usage Guide Version 1.0. http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc Committee Note Draft, 1 December 2011 [KMIP-UG-1_1] Key Management Interoperability Protocol Usage Guide Version 1.1. http://docs.oasis-open.org/kmip/ug/v1.1/cn01/kmip-ug-v1.1-cn01.doc Committee Note 01, 27 July 2012 ***** Note that the file names are identical. The link checker at: http://validator.w3.org/checklink reports 404's as follows: ***** Lines: 1290, 1307 http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. error Line: 1324 http://docs.oasis-open.org/kmip/usecases/v1.1/kmip-usecases-v1.1-cnd01.doc Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. ***** The second case of the first link, 1290, 1307 http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc, is a hidden link for [KMIP-UG-1_2].",,,Update the links to point to the correct documents., Technical Advisory Board,TAB-794 ,Link Redirects 8,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,24/Feb/14 11:23 AM,,24/Feb/14 11:23 AM,,KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0,,Public reviews,,0,,,,,Style,"The link checker at: http://validator.w3.org/checklink reports 8 link redirects as follows: ***** Line: 961 http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip redirected to https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 908 http://www.emc.com/ redirected to http://www.emc.com/index.htm Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1056 http://www.oasis-open.org/ redirected to https://www.oasis-open.org/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Lines: 900, 964 http://www.oasis-open.org/committees/kmip/ redirected to https://www.oasis-open.org/committees/kmip/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1061 http://www.oasis-open.org/policies-guidelines/trademark redirected to https://www.oasis-open.org/policies-guidelines/trademark Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Lines: 913, 921 http://www.netapp.com/ redirected to http://www.netapp.com/us/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 969 http://www.oasis-open.org/committees/kmip/ipr.php redirected to https://www.oasis-open.org/committees/kmip/ipr.php Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1000 http://www.oasis-open.org/policies-guidelines/ipr redirected to https://www.oasis-open.org/policies-guidelines/ipr Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. *****",,,Update links to use exact URLs., Technical Advisory Board,TAB-793 ,Broken HTML links 3,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,24/Feb/14 11:16 AM,,24/Feb/14 11:20 AM,,KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0,,Public reviews,,0,,,,,Style,"1.3 Non-Normative References reads in part: ***** [KMIP-UG-1_0] Key Management Interoperability Protocol Usage Guide Version 1.0. http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc Committee Note Draft, 1 December 2011 [KMIP-UG-1_1] Key Management Interoperability Protocol Usage Guide Version 1.1. http://docs.oasis-open.org/kmip/ug/v1.1/cn01/kmip-ug-v1.1-cn01.doc Committee Note 01, 27 July 2012 [KMIP-UG-1_2] Key Management Interoperability Protocol Usage Guide Version 1.2. URL hidden link: http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc ***** The link checker at: http://validator.w3.org/checklink reports: ***** Lines: 1437, 1454 http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. error Line: 1470 http://docs.oasis-open.org/kmip/usecases/v1.1/kmip-usecases-v1.1-cnd01.doc Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. ***** I grouped these together because they are references to other parts of your specification but also because there appears to be file naming confusion on the first two links. That is your text reports *identical* version numbers for versions 1.0 and 1.1. I thought that would be clearer if you check both links together. The unseen but broken link is just a pointing error that needs to be corrected.",,,Check file names and correct links as appropriate., Generated at Fri Mar 21 13:30:38 UTC 2014 by Patrick Durusau using JIRA 6.1.1#6155-sha1:7188aeec9a6b57d61ea04c52f235f15f55c105e2.,,,,,,,,,,,,,,,,,,,,,,,,,,,
,,,,,,,,,,,,,,,,,,,,,,,,,,, OASIS Technical Committees Issue Tracker ,,,,,,,,,,,,,,,,,,,,,,,,,,, Displaying 13 issues at 21/Mar/14 9:28 AM.,,,,,,,,,,,,,,,,,,,,,,,,,,, Project,Key,Summary,Issue Type,Status,Priority,Resolution,Assignee,Reporter,Created,Last Viewed,Updated,Resolved,Affects Version/s,Fix Version/s,Component/s,Due Date,Watchers,Images,Work Ratio,Sub-Tasks,Linked Issues,Environment,Description,Security Level,Labels,Proposal,Resolution Technical Advisory Board,TAB-980 ,References from Test Cases,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,21/Mar/14 8:42 AM,21/Mar/14 9:28 AM,21/Mar/14 8:42 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Technical,"Example from KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0 3.1 reads: ""This section documents the test cases that a client or server conformant to the Symmetric Key Foundry (FIPS140) Profile SHALL support under KMIP Specification 1.0."" 3.1.6 SKFF-M-6-10 reads in part: ***** Create, Locate, Get, Destroy, Locate AES-192 ***** One assumes that ""Create"" refers to some part of KMIP Specification 1.0 and refers to at least one of the test cases that follows in that section. Create should be followed by [KMIP-PROF-1_0:(section number) (title) and then followed by its test case in this profile. Otherwise which test case is for which part of KMIP-PROF-1_0 isn't clear. This is just one example. All of the test cases should have specific references of the form mentioned (to facilitate automated checking) and have the test cases separated from each other.",,,"Create separate references for each reference to a version of KMIP that consist of your key, a section number and the title of the section number, to facilitate automated checking of the references.", Technical Advisory Board,TAB-979 ,Test Case Identification,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,21/Mar/14 8:38 AM,21/Mar/14 8:38 AM,21/Mar/14 8:38 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Structure,"Example from KMIP Tape Library Profile Version 1.0 ***** The Tape Library constructs an identifier string based on the method in 2.3, then requests the server to Locate that string via ASI. A Get is then requested based on the key's unique identifier. The Tape Library MAY update attributes associated with the Symmetric Key Managed Object. The following test case shows extensive use of custom attributes. Custom attributes are not required if the Application Name is unique within the Application Namespace. An implementation may also use custom attributes for vendor-unique purposes, or to improve usability. The test case destroys the key created in the previous test case to clean up after the test. Tape Library implementations MAY not perform this step. ***** This statement is followed by test cases that are not separated from each other or have the ""custom attributes"" or goal of each test described. Every test case should be separated from every other test cases and have the conditions and goal of the test described in prose. This applies to all the test cases in the listed versions.",,,Separate each test case from others and describe its inputs/outputs and/or conditions in prose., Technical Advisory Board,TAB-972 ,Hanging Paragraphs (5),Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 11:43 AM,20/Mar/14 11:46 AM,20/Mar/14 11:46 AM,,KMIP Suite B Profile Version 1.0,,,,1,,,,,Style,"Sections 1 and 1.1 illustrate the issue with hanging paragraphs. If I say see Section 1, do I mean the paragraphs following section 1 or do I mean that + 1.1 - 1.3? Hanging paragraphs in this draft are: 1, 1.1 2, 2.1 2.1, 2.1.1 4, 4.1 4.1, 4.1.1",,,Re-section the draft to remove hanging paragraphs, Technical Advisory Board,TAB-968 ,Repetition of Appendix B?,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 10:55 AM,20/Mar/14 10:55 AM,20/Mar/14 10:55 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"Unless I am mistaken, Appendix B. KMIP Specification Cross Reference appears in all of the profiles. At the same time, all of the profiles make reference to KMIP-SPEC, where Appendix B also occurs. That is in order to use any of the profiles, the reader must also have a copy of KMIP-SPEC. In the PDF versions, that adds another five (5) pages to each profile. Or a total of 45 pages of duplicated materials, which if printed, are likely to be discarded.",,,Suggest deletion of Appendix B in all profiles in favor of the mapping which already appears in KMIP-SPEC., Technical Advisory Board,TAB-966 ,Test Cases - violation of DRY?,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 10:15 AM,21/Mar/14 9:12 AM,20/Mar/14 10:22 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"After reading over my prior comments on test cases and reviewing the test cases in the drafts, it occurred to me that the test cases follow what is already a normative statement of requirements for each profile. Yes? Taking Tape Profile 1.0 as an example, 2 Tape Library Profile defines all the normative requirements for that profile. Yes? That is to say that if I do everything in 2 Tape Library Profile, I will be conforming to that profile of KMIP-SPEC. Yes? If that's the case, the the test cases violate DRY - Don't Repeat Yourself and are unnecessary. You have said all you need to say. Why say more? I still think the test cases are valuable but would put them in a non-normative document.",,,"Move all test cases to a non-normative document and allow normative requirements to stand by themselves, without repetition.", Technical Advisory Board,TAB-934 ,Citations without section numbers,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 5:30 PM,20/Mar/14 10:03 AM,20/Mar/14 10:02 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, Key Management Interoperability Protocol Usage Guide Version 1.2, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"Just by way of example, 2.2 Suite B minLOS_128 (KMIP Suite B Profile Version 1.0) reads in part: ***** SHALL conform to the Baseline Server profile in [KMIP-PROF] and [KMIP-SPEC] and SHALL support the following Objects [KMIP-SPEC] Certificate [KMIP-SPEC] Symmetric Key [KMIP-SPEC] Public Key [KMIP-SPEC] Private Key [KMIP-SPEC] ***** Citations should include specific section numbers and titles in the cited document. I say that for two reasons: 1) The expert reader (members of this TC) are more likely to recognize an incorrect section citation by its title than by either [KMIP-SPEC] or [KMIP-SPEC:2.2.3]. Say for example if the citation were incorrect and read: [KMIP-SPEC:2.2.7], even an expert reader would be hard pressed to spot that error. On the other hand, if it read: ""Public Key [KMIP-SPEC:2.2.7 Secret Data]"" a TC member would know that wasn't the correct citation. 2) Assuming that all KMIP references between parts of this specification are written KMIP-(key):(number) (title), then it will be possible to automatically validate all of those references. For example, for KMIP-SPEC (the main document), all the section numbers and titles could be automatically extracted and then applied to a document with references to the KMIP-SPEC. By ""applied"" I mean compared to the citations in the text. Where it matches, nothing happens, but, where for whatever reason there is a KMIP cite that does not match, it is highlighted in red (for example). Proofing all the citations, at least to KMIP work, becomes a process of simply scrolling through the document looking for highlights. That won't help if the section citation is correct but substantively incorrect but only a human reader could catch that sort of error. The scripting, assuming reformation of the citations, would not take long and the actual running of the script against all the files would take less than 10 minutes. If not less. I note the work that went into Appendix B and if that effort is to be made on behalf of old users, it is much more necessary for new users of your latest work.",,,"Insert section numbers and titles for all citations of references, thus c. Public Key [KMIP-SPEC:2.2.3 Public Key] noting that ""public key"" appears all over KMIP-SPEC. The section reference makes it clear what is being referenced.", Technical Advisory Board,TAB-933 ,Missing Test Cases?,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 5:19 PM,19/Mar/14 8:15 PM,19/Mar/14 5:19 PM,,KMIP Suite B Profile Version 1.0,,,,1,,,,,Normative,"Sections 3.1 and 5.1 read: ***** 3.1 Mandatory Test Cases This section documents the test cases that a client or server conformant to this profile SHALL support. N/A 5.1 Mandatory Test Cases This section documents the test cases that a client or server conformant to this profile SHALL support. N/A ***** Are test cases missing? If there are none, simply omit these sections. (and their parents)",,,"Check to see if test cases are missing and if not, omit these sections.", Technical Advisory Board,TAB-932 ,Normative versus Non-Normative text,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 5:17 PM,19/Mar/14 5:17 PM,19/Mar/14 5:17 PM,,KMIP Suite B Profile Version 1.0,,,,1,,,,,Normative,No statement of normative versus non-normative text. Which leads to failure to distinguish normative text from non-normative text.,,,"Mark sections as normative vs. non-normative or state at the outset that introductions, notes, examples, etc. are all non-normative.", Technical Advisory Board,TAB-906 ,Normative Reference [RFC6460] Not used.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:44 AM,,18/Mar/14 11:44 AM,,KMIP Suite B Profile Version 1.0,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC6460] M. Salter and R. Housley, Suite B Profile for Transport Layer Security (TLS), IETF RFC 6460, January 2012, http://www.ietf.org/rfc/rfc6460.txt. RFC6460 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete reference., Technical Advisory Board,TAB-905 ,Normative Reference [RFC4754] Not used.,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:43 AM,,18/Mar/14 11:43 AM,,KMIP Suite B Profile Version 1.0,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC4754] D. Fu and J. Solinas, IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA), IETF RFC 4754, Jan 2007, http://www.ietf.org/rfc/rfc4754.txt. RFC4754 is not cited in this draft. Not needed as a normative reference, suggest deletion.",,,Delete reference., Technical Advisory Board,TAB-792 ,Link Redirects 8,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,24/Feb/14 11:14 AM,,24/Feb/14 11:14 AM,,KMIP Suite B Profile Version 1.0,,Public reviews,,0,,,,,Style,"The link checker at: http://validator.w3.org/checklink reports 8 link redirects as follows: ***** Line: 852 http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip redirected to https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 796 http://www.emc.com/ redirected to http://www.emc.com/index.htm Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 946 http://www.oasis-open.org/ redirected to https://www.oasis-open.org/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Lines: 788, 855 http://www.oasis-open.org/committees/kmip/ redirected to https://www.oasis-open.org/committees/kmip/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 951 http://www.oasis-open.org/policies-guidelines/trademark redirected to https://www.oasis-open.org/policies-guidelines/trademark Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 860 http://www.oasis-open.org/committees/kmip/ipr.php redirected to https://www.oasis-open.org/committees/kmip/ipr.php Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 801 http://www.netapp.com/ redirected to http://www.netapp.com/us/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 890 http://www.oasis-open.org/policies-guidelines/ipr redirected to https://www.oasis-open.org/policies-guidelines/ipr Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. *****",,,Update these links to their exact URLs., Technical Advisory Board,TAB-791 ,Broken HTML links,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,24/Feb/14 11:10 AM,,24/Feb/14 11:11 AM,,KMIP Suite B Profile Version 1.0,,Public reviews,,0,,,,,Style,"1.3 Non-Normative References reads in part: ***** [KMIP-UG-1_0] Key Management Interoperability Protocol Usage Guide Version 1.0. http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc Committee Note Draft, 1 December 2011 [KMIP-UG-1_1] Key Management Interoperability Protocol Usage Guide Version 1.1. http://docs.oasis-open.org/kmip/ug/v1.1/cn01/kmip-ug-v1.1-cn01.doc Committee Note 01, 27 July 2012 ***** The link checker at: http://validator.w3.org/checklink reports: ***** Lines: 1437, 1454 http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. ***** I grouped these together because they are references to other parts of your specification but also because there appears to be file naming confusion on the two links. That is your text reports *identical* version numbers for versions 1.0 and 1.1. I thought that would be clearer if you check both links together. The unseen but broken link is just an error but it needs to be checked before the final version.",,,Check file names and correct links as appropriate., Technical Advisory Board,TAB-790 ,Broken HTML links,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,24/Feb/14 11:08 AM,,24/Feb/14 11:08 AM,,KMIP Suite B Profile Version 1.0,,Public reviews,,0,,,,,Style,"!.3 Non-Normative References reads in part: ***** [SuiteB] Suite B Cryptography / Cryptographic Interoperability, http://www.nsa.gov/ia/programs/suiteb_cryptography/ ***** The same link occurs in 2 Suite B minLOS_128 Profile and 4 Suite B minLOS_192 Profile. The link checker at: http://validator.w3.org/checklink reports this link is broken: ***** Lines: 1438, 1452, 1784 http://www.nsa.gov/ia/programs/suiteb_cryptography/ Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. *****",,,Replace link with correct link in all three locations., Generated at Fri Mar 21 13:28:32 UTC 2014 by Patrick Durusau using JIRA 6.1.1#6155-sha1:7188aeec9a6b57d61ea04c52f235f15f55c105e2.,,,,,,,,,,,,,,,,,,,,,,,,,,,
,,,,,,,,,,,,,,,,,,,,,,,,,,, OASIS Technical Committees Issue Tracker ,,,,,,,,,,,,,,,,,,,,,,,,,,, Displaying 19 issues at 21/Mar/14 9:25 AM.,,,,,,,,,,,,,,,,,,,,,,,,,,, Project,Key,Summary,Issue Type,Status,Priority,Resolution,Assignee,Reporter,Created,Last Viewed,Updated,Resolved,Affects Version/s,Fix Version/s,Component/s,Due Date,Watchers,Images,Work Ratio,Sub-Tasks,Linked Issues,Environment,Description,Security Level,Labels,Proposal,Resolution Technical Advisory Board,TAB-980 ,References from Test Cases,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,21/Mar/14 8:42 AM,21/Mar/14 9:25 AM,21/Mar/14 8:42 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Technical,"Example from KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0 3.1 reads: ""This section documents the test cases that a client or server conformant to the Symmetric Key Foundry (FIPS140) Profile SHALL support under KMIP Specification 1.0."" 3.1.6 SKFF-M-6-10 reads in part: ***** Create, Locate, Get, Destroy, Locate AES-192 ***** One assumes that ""Create"" refers to some part of KMIP Specification 1.0 and refers to at least one of the test cases that follows in that section. Create should be followed by [KMIP-PROF-1_0:(section number) (title) and then followed by its test case in this profile. Otherwise which test case is for which part of KMIP-PROF-1_0 isn't clear. This is just one example. All of the test cases should have specific references of the form mentioned (to facilitate automated checking) and have the test cases separated from each other.",,,"Create separate references for each reference to a version of KMIP that consist of your key, a section number and the title of the section number, to facilitate automated checking of the references.", Technical Advisory Board,TAB-979 ,Test Case Identification,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,21/Mar/14 8:38 AM,21/Mar/14 8:38 AM,21/Mar/14 8:38 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Structure,"Example from KMIP Tape Library Profile Version 1.0 ***** The Tape Library constructs an identifier string based on the method in 2.3, then requests the server to Locate that string via ASI. A Get is then requested based on the key's unique identifier. The Tape Library MAY update attributes associated with the Symmetric Key Managed Object. The following test case shows extensive use of custom attributes. Custom attributes are not required if the Application Name is unique within the Application Namespace. An implementation may also use custom attributes for vendor-unique purposes, or to improve usability. The test case destroys the key created in the previous test case to clean up after the test. Tape Library implementations MAY not perform this step. ***** This statement is followed by test cases that are not separated from each other or have the ""custom attributes"" or goal of each test described. Every test case should be separated from every other test cases and have the conditions and goal of the test described in prose. This applies to all the test cases in the listed versions.",,,Separate each test case from others and describe its inputs/outputs and/or conditions in prose., Technical Advisory Board,TAB-971 ,Hanging Paragraphs (10),Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 11:41 AM,20/Mar/14 11:42 AM,20/Mar/14 11:41 AM,,KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0,,,,1,,,,,Style,"Sections 1 and 1.1 illustrate the issue with hanging paragraphs. If I say see Section 1, do I mean the paragraphs following section 1 or do I mean that + 1.1 - 1.3? Hanging paragraphs in this draft are: 1, 1.1 2, 2.1 3, 3.1 3.1, 3.1.1 3.2, 3.2.1 3.3, 3.3.1 3.4, 3.4.1 3.5, 3.5.1 3.6, 3.6.1 4.2, 4.2.1",,,Re-section the draft to remove hanging paragraphs, Technical Advisory Board,TAB-968 ,Repetition of Appendix B?,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 10:55 AM,20/Mar/14 10:55 AM,20/Mar/14 10:55 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"Unless I am mistaken, Appendix B. KMIP Specification Cross Reference appears in all of the profiles. At the same time, all of the profiles make reference to KMIP-SPEC, where Appendix B also occurs. That is in order to use any of the profiles, the reader must also have a copy of KMIP-SPEC. In the PDF versions, that adds another five (5) pages to each profile. Or a total of 45 pages of duplicated materials, which if printed, are likely to be discarded.",,,Suggest deletion of Appendix B in all profiles in favor of the mapping which already appears in KMIP-SPEC., Technical Advisory Board,TAB-966 ,Test Cases - violation of DRY?,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 10:15 AM,21/Mar/14 9:12 AM,20/Mar/14 10:22 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"After reading over my prior comments on test cases and reviewing the test cases in the drafts, it occurred to me that the test cases follow what is already a normative statement of requirements for each profile. Yes? Taking Tape Profile 1.0 as an example, 2 Tape Library Profile defines all the normative requirements for that profile. Yes? That is to say that if I do everything in 2 Tape Library Profile, I will be conforming to that profile of KMIP-SPEC. Yes? If that's the case, the the test cases violate DRY - Don't Repeat Yourself and are unnecessary. You have said all you need to say. Why say more? I still think the test cases are valuable but would put them in a non-normative document.",,,"Move all test cases to a non-normative document and allow normative requirements to stand by themselves, without repetition.", Technical Advisory Board,TAB-965 ,Conformance clause should be per conformance target:,Improvement,New,Major,Unresolved,Unassigned,Jacques Durand,19/Mar/14 9:53 PM,20/Mar/14 9:34 AM,19/Mar/14 9:53 PM,,KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0,,Public reviews,,1,,,,,Conformance,"Conformance clause should be per conformance target: There should be two different conformance clauses for two conformance targets as different as CLient & Server, instead of a single clause that expresses the same requirements regardless of the type of implementation. Also, there seems to be a reference error in the text: "" 3. Shall support all Mandatory Test Cases (3.1, Error! Reference source not found. and 3.3 ), """,,,, Technical Advisory Board,TAB-964 ,Confusing redundancy in conformance statements outside conformance clause,Improvement,New,Major,Unresolved,Unassigned,Jacques Durand,19/Mar/14 9:51 PM,,19/Mar/14 9:51 PM,,KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0,,Public reviews,,1,,,,,Structure,"Confusing redundancy in conformance statements outside conformance clause: Similar comment made in other documents, about some conformance statements made outside the Conformance section. ""section 2.1 and 2.2"" are clearly redundant with :""section 4 ""Conformance"". Both pretend to be a conformance clause for Client and Server. Sections 2 should merge into the Conformance section: there should not be any conformance statement outside the conformance section.",,,, Technical Advisory Board,TAB-963 ,"What it means to ""support a Mandatory Test Case"" is not clearly & normatively defined",Improvement,New,Major,Unresolved,Unassigned,Jacques Durand,19/Mar/14 9:48 PM,,19/Mar/14 9:48 PM,,KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0,,Public reviews,,1,,,,,Normative,"What it means to ""support a Mandatory Test Case"" is not clearly & normatively defined. Similar comment made in other documents, about the necessity to define what a ""normative interpretation"" of these test cases is - i.e. what it means to ""support a Mandatory Test Case"" . The ""Permitted Test Case Variations"" should be part of that normative interpretation, but there is more to it. A normative interpretation (of Test Cases) defined as part of the specification is needed, because these Test Cases are used in a conformance clause and therefore are parts of the specification too, as opposed to being part of a test suite outside the specification. They are used as part of the definition of conformance, not just part of of a test suite to *verify* if an implementation adheres to a conformance definition otherwise self-sufficient and independent from any test case by itself. This is not quite the same thing. See comment TAB-962 for a suggestion on how to give normative meaning to test Cases in the profile specification.",,,, Technical Advisory Board,TAB-962 ,Suggestion for a normative interpretation of Test Cases,Improvement,New,Major,Unresolved,Unassigned,Jacques Durand,19/Mar/14 9:37 PM,,19/Mar/14 10:33 PM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0",,Public reviews,,1,,,,,Normative,"Suggestion for a normative interpretation of Test Cases: Since many KMIP profiles are specified in terms of ""test cases"", a normative interpretation should be given for these test cases. This could be done as a set of rules, that determine what the ""response"" should look like based on the ""Request"" message (assuming the implementation under test, i.e. the conformance target, is the one producing the response). These rules would be generic as much as possible (apply to all test cases in a profile at least). These rules can look like:. 1. Schema rule(s): when receiving a Request that satisfies [XML?] schema X, the implementation MUST send back a response that satisfies [XML?] schema Y. 2. Error rule(s): when receiving a Request that is incorrect (for various reasons) , the implementation MUST (or SHOULD?) send back a response that is of the form.... 3. Processing scope rules: they state what kind of Request content variations (both in terms of atomic values and optional elements) an implementation MUST accept (i.e. process and return something else than an Error). 4. Content dependency rules: these would capture several of the ""test case variation"" response cases, but establish a clear dependency rule with similar or related content in the Request.(i.e. how the Request content determines the Response content) 5. Independent variation rules: hese would restate several of the ""test case variation"" cases, that are independent from the Request content or the dependency of which is not easily expressed nor obvious. But maybe a range of resulting values can be stated. Such normative rules would be part of the specification body, but referred by the COnformance clause. With such rules, the Conformance Clause (for related implementation ) can say: ""[KMIP server] when receiving a Request matching any of the Mandatory test Cases (where ""matching"" allows variations as stated by rules X,Y,Z) , the [server] MUST generate a Response that satisfies the rules 1,2,3,4,5. when applied to the test case response."" instead of: ""support all Mandatory Test Cases (3.1and 3.2 and 3.3), for each supported protocol version (major and minor), returning results in accordance with the test cases."" Note you can then remove the confusingly vague statement: ""Note: the values for the returned items and the custom attributes are illustrative. Actual values from a real client system will vary. "" As this variability would be now defined by normative ""rules"". You can then state that all these test cases (along with their usage or variation rules) are normative content.",,,, Technical Advisory Board,TAB-934 ,Citations without section numbers,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 5:30 PM,20/Mar/14 10:03 AM,20/Mar/14 10:02 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, Key Management Interoperability Protocol Usage Guide Version 1.2, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"Just by way of example, 2.2 Suite B minLOS_128 (KMIP Suite B Profile Version 1.0) reads in part: ***** SHALL conform to the Baseline Server profile in [KMIP-PROF] and [KMIP-SPEC] and SHALL support the following Objects [KMIP-SPEC] Certificate [KMIP-SPEC] Symmetric Key [KMIP-SPEC] Public Key [KMIP-SPEC] Private Key [KMIP-SPEC] ***** Citations should include specific section numbers and titles in the cited document. I say that for two reasons: 1) The expert reader (members of this TC) are more likely to recognize an incorrect section citation by its title than by either [KMIP-SPEC] or [KMIP-SPEC:2.2.3]. Say for example if the citation were incorrect and read: [KMIP-SPEC:2.2.7], even an expert reader would be hard pressed to spot that error. On the other hand, if it read: ""Public Key [KMIP-SPEC:2.2.7 Secret Data]"" a TC member would know that wasn't the correct citation. 2) Assuming that all KMIP references between parts of this specification are written KMIP-(key):(number) (title), then it will be possible to automatically validate all of those references. For example, for KMIP-SPEC (the main document), all the section numbers and titles could be automatically extracted and then applied to a document with references to the KMIP-SPEC. By ""applied"" I mean compared to the citations in the text. Where it matches, nothing happens, but, where for whatever reason there is a KMIP cite that does not match, it is highlighted in red (for example). Proofing all the citations, at least to KMIP work, becomes a process of simply scrolling through the document looking for highlights. That won't help if the section citation is correct but substantively incorrect but only a human reader could catch that sort of error. The scripting, assuming reformation of the citations, would not take long and the actual running of the script against all the files would take less than 10 minutes. If not less. I note the work that went into Appendix B and if that effort is to be made on behalf of old users, it is much more necessary for new users of your latest work.",,,"Insert section numbers and titles for all citations of references, thus c. Public Key [KMIP-SPEC:2.2.3 Public Key] noting that ""public key"" appears all over KMIP-SPEC. The section reference makes it clear what is being referenced.", Technical Advisory Board,TAB-931 ,Conformance based on Test Cases,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 5:09 PM,19/Mar/14 5:14 PM,19/Mar/14 5:09 PM,,KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0,,,,1,,,,,Normative,"Test cases are referenced in the conformance clauses, but only the test can be normative. As the draft states, the results may vary from those shown. If the results may vary, an implementer can't judge if they have properly pass the test case required for conformance. 4.1 Conformance Statement says in part: ""Shall support all Mandatory Test Cases (3.1, Error! Reference source not found. and 3.3 ), for each supported protocol version (major and minor), returning results in accordance with the test cases."" But we already know that can't happen as per 3. Symmetric Key Foundary (FIPS140) Profile - Test Cases.",,,"As I suggest in another comment, all test cases should be moved to Key Management Interoperability Protocol Test Cases Version 1.2 (or some other non-normative document) and reform conformance clauses to not depend on test cases.", Technical Advisory Board,TAB-930 ,Test Cases - Structure,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 5:06 PM,19/Mar/14 8:20 PM,19/Mar/14 8:20 PM,,KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0,,,,1,,,,,Normative,"From Key Management Interoperability Protocol Test Cases Version 1.2 1 Introduction reads: ""The purpose of this document is to describe test cases to demonstrate the Key Management Interoperability Protocol (KMIP) [KMIP-SPEC-1_2], [KMIP-SPEC-1_1], and [KMIP-SPEC-1_0]. The test cases illustrate that the concepts within the protocol are sound and how the protocol may be used when implementing KMIP in applications. These test cases are not intended to fully test an implementation of KMIP. There are test cases for v1.0, v1.1 and v1.2 of the protocol."" And 2 KMIP Test Cases reads in part: ""The test cases show one possible way to construct the messages, and the messages shown are not necessarily the only conformant constructions as many items within KMIP are optional and server behavior depends on the server's policy. Support for a test case is predicated on a server matching the test case assumptions and the behavior shown in the request-response pairs."" If that is true for KMIP 1.2, it is certainly also true for KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0. A more useful location for the test cases would be in Key Management Interoperability Protocol Test Cases Version 1.2 and for the conformance clauses of KMIP Symmetric Key Foundry for FIPS 140-2 Profile to be written without reference to test cases. Which as noted above, doesn't really test all of a standard.",,,"Move test cases to Key Management Interoperability Protocol Test Cases Version 1.2, reform conformance clauses to not depend on test cases.", Technical Advisory Board,TAB-929 ,Test Cases - No reference for type constraints,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 5:03 PM,,19/Mar/14 5:03 PM,,KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0,,,,1,,,,,Technical,"The test cases that appear in XML markup contain attribute value restrictions. However, there is no normative citation of value definitions nor is there a schema to enforce those definitions, if given.",,,Normative citation of XML Schema Part 2 plus an XML schema for the test cases as defined are required at a minimum. Usefulness for users also requires the test cases in machine readable XML format., Technical Advisory Board,TAB-928 ,Test Cases - Normative vs. Non-Normative,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 5:02 PM,,19/Mar/14 5:02 PM,,KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0,,,,1,,,,,Normative,"The Note in 3 reads in part: ""the values for time stamps are illustrative. Actual values from a real server system will vary."" If the test cases are normative, then the responses are not and should be so marked. If the test cases are non-normative, then all should be marked as non-normative.",,,Mark all or part of use cases as non-normative as appropriate, Technical Advisory Board,TAB-927 ,Note: distinguish,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 4:59 PM,,19/Mar/14 4:59 PM,,KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0,,,,1,,,,,Style,"The ""Note"" in section 3 needs to be typographically distinct and non-normative. Easiest way is to declare all notes as non-normative.",,,Make all notes typographically distinct and declare notes to be non-normative., Technical Advisory Board,TAB-926 ,Normative versus Non-Normative Text,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 4:57 PM,,19/Mar/14 4:57 PM,,KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0,,,,1,,,,,Normative,"No statement of normative versus non-normative text. 3. Symmetric Key Foundry (FIPS140) Profile - Test Cases - reads in part: ""Note: the values for time stamps are illustrative. Actual values from a real server system will vary."" ***** Only values of time stamps vary? Other parts say: ""the values for the returned items and the custom attributes are illustrative."" Illustrative material is be definition non-normative",,,"Mark non-normative text as such and/or declare parts of the text, such as notes, examples, etc. as non-normative.", Technical Advisory Board,TAB-904 ,Duplicated Reference,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:42 AM,,18/Mar/14 11:42 AM,,KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0,,,,1,,,,,References,1.2 Normative References has two citations to RFC2119.,,,Delete one (1) reference to RFC2119., Technical Advisory Board,TAB-903 ,Obsoleted Reference,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:40 AM,,18/Mar/14 11:41 AM,,KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0,,,,1,,,,,References,"1.2 Normative References reads in part: [RFC2246] T. Dierks and C. Allen, The TLS Protocol, Version 1.0, IETF RFC 2246, Jan 1999, http://www.ietf.org/rfc/rfc2246.txt The RFC editor's list at: http://www.rfc-editor.org/in-notes/rfc-ref.txt shows RFC2246 as superseded by RFC4346, which was itself superseded by RFC5246, which should be cited as: [RFC5246] Dierks, T. and E. Rescorla, ""The Transport Layer Security (TLS) Protocol Version 1.2"", RFC 5246, August 2008. http://www.ietf.org/rfc/rfc5246.txt Superseded references should not be cited in current work. Suggest updating the reference. On the other hand, since RFC2246 is not cited in this draft, you probably should just delete it.",,,Update or delete., Technical Advisory Board,TAB-789 ,Link Redirects 9,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,24/Feb/14 9:59 AM,,24/Feb/14 9:59 AM,,KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0,,Public reviews,,0,,,,,Style,"The link checker at: http://validator.w3.org/checklink reports 9 link redirects as follows: ***** Line: 960 http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip redirected to https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 907 http://www.emc.com/ redirected to http://www.emc.com/index.htm Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 921 http://www.thales-esecurity.com/ redirected to https://www.thales-esecurity.com/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1054 http://www.oasis-open.org/ redirected to https://www.oasis-open.org/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Lines: 899, 963 http://www.oasis-open.org/committees/kmip/ redirected to https://www.oasis-open.org/committees/kmip/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1059 http://www.oasis-open.org/policies-guidelines/trademark redirected to https://www.oasis-open.org/policies-guidelines/trademark Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 968 http://www.oasis-open.org/committees/kmip/ipr.php redirected to https://www.oasis-open.org/committees/kmip/ipr.php Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 912 http://www.netapp.com/ redirected to http://www.netapp.com/us/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 998 http://www.oasis-open.org/policies-guidelines/ipr redirected to https://www.oasis-open.org/policies-guidelines/ipr Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. *****",,,Update these links to use their exact URLs., Generated at Fri Mar 21 13:25:51 UTC 2014 by Patrick Durusau using JIRA 6.1.1#6155-sha1:7188aeec9a6b57d61ea04c52f235f15f55c105e2.,,,,,,,,,,,,,,,,,,,,,,,,,,,
,,,,,,,,,,,,,,,,,,,,,,,,,,, OASIS Technical Committees Issue Tracker ,,,,,,,,,,,,,,,,,,,,,,,,,,, Displaying 16 issues at 21/Mar/14 9:23 AM.,,,,,,,,,,,,,,,,,,,,,,,,,,, Project,Key,Summary,Issue Type,Status,Priority,Resolution,Assignee,Reporter,Created,Last Viewed,Updated,Resolved,Affects Version/s,Fix Version/s,Component/s,Due Date,Watchers,Images,Work Ratio,Sub-Tasks,Linked Issues,Environment,Description,Security Level,Labels,Proposal,Resolution Technical Advisory Board,TAB-980 ,References from Test Cases,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,21/Mar/14 8:42 AM,21/Mar/14 9:23 AM,21/Mar/14 8:42 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Technical,"Example from KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0 3.1 reads: ""This section documents the test cases that a client or server conformant to the Symmetric Key Foundry (FIPS140) Profile SHALL support under KMIP Specification 1.0."" 3.1.6 SKFF-M-6-10 reads in part: ***** Create, Locate, Get, Destroy, Locate AES-192 ***** One assumes that ""Create"" refers to some part of KMIP Specification 1.0 and refers to at least one of the test cases that follows in that section. Create should be followed by [KMIP-PROF-1_0:(section number) (title) and then followed by its test case in this profile. Otherwise which test case is for which part of KMIP-PROF-1_0 isn't clear. This is just one example. All of the test cases should have specific references of the form mentioned (to facilitate automated checking) and have the test cases separated from each other.",,,"Create separate references for each reference to a version of KMIP that consist of your key, a section number and the title of the section number, to facilitate automated checking of the references.", Technical Advisory Board,TAB-979 ,Test Case Identification,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,21/Mar/14 8:38 AM,21/Mar/14 8:38 AM,21/Mar/14 8:38 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Structure,"Example from KMIP Tape Library Profile Version 1.0 ***** The Tape Library constructs an identifier string based on the method in 2.3, then requests the server to Locate that string via ASI. A Get is then requested based on the key's unique identifier. The Tape Library MAY update attributes associated with the Symmetric Key Managed Object. The following test case shows extensive use of custom attributes. Custom attributes are not required if the Application Name is unique within the Application Namespace. An implementation may also use custom attributes for vendor-unique purposes, or to improve usability. The test case destroys the key created in the previous test case to clean up after the test. Tape Library implementations MAY not perform this step. ***** This statement is followed by test cases that are not separated from each other or have the ""custom attributes"" or goal of each test described. Every test case should be separated from every other test cases and have the conditions and goal of the test described in prose. This applies to all the test cases in the listed versions.",,,Separate each test case from others and describe its inputs/outputs and/or conditions in prose., Technical Advisory Board,TAB-970 ,Hanging Paragraphs (11),Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 11:16 AM,20/Mar/14 11:42 AM,20/Mar/14 11:16 AM,,KMIP Symmetric Key Lifecycle Profile Version 1.0,,,,1,,,,,Style,"Sections 1 and 1.1 illustrate the issue with hanging paragraphs. If I say see Section 1, do I mean the paragraphs following section 1 or do I mean that + 1.1 - 1.3? Hanging paragraphs in this draft are: 1, 1.1 2, 2.1 3, 3.1 3.1, 3.1.1 3.2, 3.2.1 3.3, 3.3.1 3.4, 3.4.1 3.5, 3.5.1 3.6, 3.6.1 4, 4.1 (note the lack of test cases, suggest delete this section entirely) 5.2, 5.2.1",,,Re-section the draft to remove hanging paragraphs, Technical Advisory Board,TAB-968 ,Repetition of Appendix B?,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 10:55 AM,20/Mar/14 10:55 AM,20/Mar/14 10:55 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"Unless I am mistaken, Appendix B. KMIP Specification Cross Reference appears in all of the profiles. At the same time, all of the profiles make reference to KMIP-SPEC, where Appendix B also occurs. That is in order to use any of the profiles, the reader must also have a copy of KMIP-SPEC. In the PDF versions, that adds another five (5) pages to each profile. Or a total of 45 pages of duplicated materials, which if printed, are likely to be discarded.",,,Suggest deletion of Appendix B in all profiles in favor of the mapping which already appears in KMIP-SPEC., Technical Advisory Board,TAB-966 ,Test Cases - violation of DRY?,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 10:15 AM,21/Mar/14 9:12 AM,20/Mar/14 10:22 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"After reading over my prior comments on test cases and reviewing the test cases in the drafts, it occurred to me that the test cases follow what is already a normative statement of requirements for each profile. Yes? Taking Tape Profile 1.0 as an example, 2 Tape Library Profile defines all the normative requirements for that profile. Yes? That is to say that if I do everything in 2 Tape Library Profile, I will be conforming to that profile of KMIP-SPEC. Yes? If that's the case, the the test cases violate DRY - Don't Repeat Yourself and are unnecessary. You have said all you need to say. Why say more? I still think the test cases are valuable but would put them in a non-normative document.",,,"Move all test cases to a non-normative document and allow normative requirements to stand by themselves, without repetition.", Technical Advisory Board,TAB-962 ,Suggestion for a normative interpretation of Test Cases,Improvement,New,Major,Unresolved,Unassigned,Jacques Durand,19/Mar/14 9:37 PM,,19/Mar/14 10:33 PM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0",,Public reviews,,1,,,,,Normative,"Suggestion for a normative interpretation of Test Cases: Since many KMIP profiles are specified in terms of ""test cases"", a normative interpretation should be given for these test cases. This could be done as a set of rules, that determine what the ""response"" should look like based on the ""Request"" message (assuming the implementation under test, i.e. the conformance target, is the one producing the response). These rules would be generic as much as possible (apply to all test cases in a profile at least). These rules can look like:. 1. Schema rule(s): when receiving a Request that satisfies [XML?] schema X, the implementation MUST send back a response that satisfies [XML?] schema Y. 2. Error rule(s): when receiving a Request that is incorrect (for various reasons) , the implementation MUST (or SHOULD?) send back a response that is of the form.... 3. Processing scope rules: they state what kind of Request content variations (both in terms of atomic values and optional elements) an implementation MUST accept (i.e. process and return something else than an Error). 4. Content dependency rules: these would capture several of the ""test case variation"" response cases, but establish a clear dependency rule with similar or related content in the Request.(i.e. how the Request content determines the Response content) 5. Independent variation rules: hese would restate several of the ""test case variation"" cases, that are independent from the Request content or the dependency of which is not easily expressed nor obvious. But maybe a range of resulting values can be stated. Such normative rules would be part of the specification body, but referred by the COnformance clause. With such rules, the Conformance Clause (for related implementation ) can say: ""[KMIP server] when receiving a Request matching any of the Mandatory test Cases (where ""matching"" allows variations as stated by rules X,Y,Z) , the [server] MUST generate a Response that satisfies the rules 1,2,3,4,5. when applied to the test case response."" instead of: ""support all Mandatory Test Cases (3.1and 3.2 and 3.3), for each supported protocol version (major and minor), returning results in accordance with the test cases."" Note you can then remove the confusingly vague statement: ""Note: the values for the returned items and the custom attributes are illustrative. Actual values from a real client system will vary. "" As this variability would be now defined by normative ""rules"". You can then state that all these test cases (along with their usage or variation rules) are normative content.",,,, Technical Advisory Board,TAB-934 ,Citations without section numbers,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 5:30 PM,20/Mar/14 10:03 AM,20/Mar/14 10:02 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, Key Management Interoperability Protocol Usage Guide Version 1.2, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"Just by way of example, 2.2 Suite B minLOS_128 (KMIP Suite B Profile Version 1.0) reads in part: ***** SHALL conform to the Baseline Server profile in [KMIP-PROF] and [KMIP-SPEC] and SHALL support the following Objects [KMIP-SPEC] Certificate [KMIP-SPEC] Symmetric Key [KMIP-SPEC] Public Key [KMIP-SPEC] Private Key [KMIP-SPEC] ***** Citations should include specific section numbers and titles in the cited document. I say that for two reasons: 1) The expert reader (members of this TC) are more likely to recognize an incorrect section citation by its title than by either [KMIP-SPEC] or [KMIP-SPEC:2.2.3]. Say for example if the citation were incorrect and read: [KMIP-SPEC:2.2.7], even an expert reader would be hard pressed to spot that error. On the other hand, if it read: ""Public Key [KMIP-SPEC:2.2.7 Secret Data]"" a TC member would know that wasn't the correct citation. 2) Assuming that all KMIP references between parts of this specification are written KMIP-(key):(number) (title), then it will be possible to automatically validate all of those references. For example, for KMIP-SPEC (the main document), all the section numbers and titles could be automatically extracted and then applied to a document with references to the KMIP-SPEC. By ""applied"" I mean compared to the citations in the text. Where it matches, nothing happens, but, where for whatever reason there is a KMIP cite that does not match, it is highlighted in red (for example). Proofing all the citations, at least to KMIP work, becomes a process of simply scrolling through the document looking for highlights. That won't help if the section citation is correct but substantively incorrect but only a human reader could catch that sort of error. The scripting, assuming reformation of the citations, would not take long and the actual running of the script against all the files would take less than 10 minutes. If not less. I note the work that went into Appendix B and if that effort is to be made on behalf of old users, it is much more necessary for new users of your latest work.",,,"Insert section numbers and titles for all citations of references, thus c. Public Key [KMIP-SPEC:2.2.3 Public Key] noting that ""public key"" appears all over KMIP-SPEC. The section reference makes it clear what is being referenced.", Technical Advisory Board,TAB-902 ,Duplicated Reference,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:28 AM,,18/Mar/14 11:28 AM,,KMIP Symmetric Key Lifecycle Profile Version 1.0,,,,1,,,,,References,1.2 Normative References has two citations to RFC2119.,,,Delete one (1) reference to RFC 2119., Technical Advisory Board,TAB-901 ,Obsoleted Reference,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:27 AM,,18/Mar/14 11:27 AM,,KMIP Symmetric Key Lifecycle Profile Version 1.0,,,,1,,,,,References,"Obsoleted Reference 1.2 Normative References reads in part: [RFC2246] T. Dierks and C. Allen, The TLS Protocol, Version 1.0, IETF RFC 2246, Jan 1999, http://www.ietf.org/rfc/rfc2246.txt The RFC editor's list at: http://www.rfc-editor.org/in-notes/rfc-ref.txt shows RFC2246 as superseded by RFC4346, which was itself superseded by RFC5246, which should be cited as: [RFC5246] Dierks, T. and E. Rescorla, ""The Transport Layer Security (TLS) Protocol Version 1.2"", RFC 5246, August 2008. http://www.ietf.org/rfc/rfc5246.txt Superseded references should not be cited in current work. Suggest updating the reference. On the other hand, since RFC2246 is not cited in this draft, you probably should just delete it.",,,Update or delete., Technical Advisory Board,TAB-900 ,Note - style,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:26 AM,,18/Mar/14 11:26 AM,,KMIP Symmetric Key Lifecycle Profile Version 1.0,,,,1,,,,,Style,"3 Symmetric Key Lifecycle Profile - Test Cases reads in part: ""Note: the values for the returned items and the custom attributes are illustrative. Actual values from a real client system will vary."" Notes need to be typographically distinct and are non-normative. Easiest way is to declare all notes as non-normative.",,,Format all notes to make them distinct from the main text and declare notes to be non-normative., Technical Advisory Board,TAB-899 ,Test Cases - Structure,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:24 AM,19/Mar/14 8:18 PM,18/Mar/14 11:34 AM,,KMIP Symmetric Key Lifecycle Profile Version 1.0,,,,1,,,,,Structure,"From Key Management Interoperability Protocol Test Cases Version 1.2 1 Introduction reads: ""The purpose of this document is to describe test cases to demonstrate the Key Management Interoperability Protocol (KMIP) [KMIP-SPEC-1_2], [KMIP-SPEC-1_1], and [KMIP-SPEC-1_0]. The test cases illustrate that the concepts within the protocol are sound and how the protocol may be used when implementing KMIP in applications. These test cases are not intended to fully test an implementation of KMIP. There are test cases for v1.0, v1.1 and v1.2 of the protocol."" And 2 KMIP Test Cases reads in part: ""The test cases show one possible way to construct the messages, and the messages shown are not necessarily the only conformant constructions as many items within KMIP are optional and server behavior depends on the server's policy. Support for a test case is predicated on a server matching the test case assumptions and the behavior shown in the request-response pairs."" If this is true for KMIP 1.2, it is also true for Symmetric Key Lifecycle Profile version 1.0.",,,"Move all test cases to: Key Management Interoperability Protocol Test Cases Version 1.2 and restate conformance clauses to not rely on test cases, which don't fully test a standard.", Technical Advisory Board,TAB-898 ,Test Cases - No reference for type constraints,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:21 AM,,18/Mar/14 11:21 AM,,KMIP Symmetric Key Lifecycle Profile Version 1.0,,,,1,,,,,Normative,The test cases include value constraints without citation of XML Schema Part 2 and without an XML schema to enforce those restrictions.,,,Normative citation of XML Schema Part 2 plus an XML schema for the test cases as defined are required at a minimum. Usefulness for users also requires the test cases in machine readable XML format., Technical Advisory Board,TAB-897 ,Test Cases - Normative vs. non-normative,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:18 AM,,18/Mar/14 11:18 AM,,KMIP Symmetric Key Lifecycle Profile Version 1.0,,,,1,,,,,Normative,"3 Symmetric Key Lifecycle Profile - Test Cases - reads in part: ""Note: the values for the returned items and the custom attributes are illustrative. Actual values from a real client system will vary."" If that is the case, then at least the responses shown are non-normative but not marked as such.",,,Mark all responses as non-normative and/or all of test cases as non-normative., Technical Advisory Board,TAB-788 ,Broken HTML links,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,24/Feb/14 9:56 AM,,24/Feb/14 9:56 AM,,KMIP Symmetric Key Lifecycle Profile Version 1.0,,Public reviews,,0,,,,,Style,"1.3 Non-Normative References reads in part: ***** [KMIP-UG-1_0] Key Management Interoperability Protocol Usage Guide Version 1.0. http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc Committee Note Draft, 1 December 2011 [KMIP-UG-1_1] Key Management Interoperability Protocol Usage Guide Version 1.1. http://docs.oasis-open.org/kmip/ug/v1.1/cn01/kmip-ug-v1.1-cn01.doc Committee Note 01, 27 July 2012 [KMIP-UG-1_2] Key Management Interoperability Protocol Usage Guide Version 1.2. URL (has a bad hidden link) ***** The link checker at: http://validator.w3.org/checklink reports: ***** Lines: 1437, 1454 http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. error Line: 1470 http://docs.oasis-open.org/kmip/usecases/v1.1/kmip-usecases-v1.1-cnd01.doc Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. ***** I grouped these together because they are references to other parts of your specification but also because there appears to be file naming confusion on the first two links. That is your text reports *identical* version numbers for versions 1.0 and 1.1. I thought that would be clearer if you check both links together. The unseen but broken link is just an error but it needs to be checked before the final version.",,,Check file names and correct links as appropriate., Technical Advisory Board,TAB-787 ,Link Redirects - 9,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,24/Feb/14 9:53 AM,,24/Feb/14 9:53 AM,,KMIP Symmetric Key Lifecycle Profile Version 1.0,,,,0,,,,,Style,"The link checker at: http://validator.w3.org/checklink reports 9 redirects as follows: ***** Line: 959 http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip redirected to https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 907 http://www.emc.com/ redirected to http://www.emc.com/index.htm Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 921 http://www.thales-esecurity.com/ redirected to https://www.thales-esecurity.com/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1054 http://www.oasis-open.org/ redirected to https://www.oasis-open.org/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Lines: 899, 962 http://www.oasis-open.org/committees/kmip/ redirected to https://www.oasis-open.org/committees/kmip/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1059 http://www.oasis-open.org/policies-guidelines/trademark redirected to https://www.oasis-open.org/policies-guidelines/trademark Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 967 http://www.oasis-open.org/committees/kmip/ipr.php redirected to https://www.oasis-open.org/committees/kmip/ipr.php Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 912 http://www.netapp.com/ redirected to http://www.netapp.com/us/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 998 http://www.oasis-open.org/policies-guidelines/ipr redirected to https://www.oasis-open.org/policies-guidelines/ipr Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. *****",,,Update these links to use the exact URLs., Technical Advisory Board,TAB-786 ,Broken HTML links,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,24/Feb/14 9:50 AM,,24/Feb/14 9:51 AM,,KMIP Symmetric Key Lifecycle Profile Version 1.0,,Public reviews,,0,,,,,Style,"1.3 Non-Normative References reads in part: ***** [KMIP-UG-1_0] Key Management Interoperability Protocol Usage Guide Version 1.0. http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc Committee Note Draft, 1 December 2011 [KMIP-UG-1_1] Key Management Interoperability Protocol Usage Guide Version 1.1. http://docs.oasis-open.org/kmip/ug/v1.1/cn01/kmip-ug-v1.1-cn01.doc Committee Note 01, 27 July 2012 [KMIP-UG-1_2] Key Management Interoperability Protocol Usage Guide Version 1.2. URL (has a bad hidden link) ***** The link checker at: http://validator.w3.org/checklink reports: ***** Lines: 1437, 1454 http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. error Line: 1470 http://docs.oasis-open.org/kmip/usecases/v1.1/kmip-usecases-v1.1-cnd01.doc Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. ***** I grouped these together because they are references to other parts of your specification but also because there appears to be file naming confusion on the first two links. That is your text reports *identical* version numbers for versions 1.0 and 1.1. I thought that would be clearer if you check both links together. The unseen but broken link is just an error but it needs to be checked before the final version.",,,Check file names and correct links as appropriate., Generated at Fri Mar 21 13:23:44 UTC 2014 by Patrick Durusau using JIRA 6.1.1#6155-sha1:7188aeec9a6b57d61ea04c52f235f15f55c105e2.,,,,,,,,,,,,,,,,,,,,,,,,,,,
,,,,,,,,,,,,,,,,,,,,,,,,,,, OASIS Technical Committees Issue Tracker ,,,,,,,,,,,,,,,,,,,,,,,,,,, Displaying 16 issues at 21/Mar/14 9:20 AM.,,,,,,,,,,,,,,,,,,,,,,,,,,, Project,Key,Summary,Issue Type,Status,Priority,Resolution,Assignee,Reporter,Created,Last Viewed,Updated,Resolved,Affects Version/s,Fix Version/s,Component/s,Due Date,Watchers,Images,Work Ratio,Sub-Tasks,Linked Issues,Environment,Description,Security Level,Labels,Proposal,Resolution Technical Advisory Board,TAB-980 ,References from Test Cases,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,21/Mar/14 8:42 AM,21/Mar/14 9:20 AM,21/Mar/14 8:42 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Technical,"Example from KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0 3.1 reads: ""This section documents the test cases that a client or server conformant to the Symmetric Key Foundry (FIPS140) Profile SHALL support under KMIP Specification 1.0."" 3.1.6 SKFF-M-6-10 reads in part: ***** Create, Locate, Get, Destroy, Locate AES-192 ***** One assumes that ""Create"" refers to some part of KMIP Specification 1.0 and refers to at least one of the test cases that follows in that section. Create should be followed by [KMIP-PROF-1_0:(section number) (title) and then followed by its test case in this profile. Otherwise which test case is for which part of KMIP-PROF-1_0 isn't clear. This is just one example. All of the test cases should have specific references of the form mentioned (to facilitate automated checking) and have the test cases separated from each other.",,,"Create separate references for each reference to a version of KMIP that consist of your key, a section number and the title of the section number, to facilitate automated checking of the references.", Technical Advisory Board,TAB-979 ,Test Case Identification,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,21/Mar/14 8:38 AM,21/Mar/14 8:38 AM,21/Mar/14 8:38 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Structure,"Example from KMIP Tape Library Profile Version 1.0 ***** The Tape Library constructs an identifier string based on the method in 2.3, then requests the server to Locate that string via ASI. A Get is then requested based on the key's unique identifier. The Tape Library MAY update attributes associated with the Symmetric Key Managed Object. The following test case shows extensive use of custom attributes. Custom attributes are not required if the Application Name is unique within the Application Namespace. An implementation may also use custom attributes for vendor-unique purposes, or to improve usability. The test case destroys the key created in the previous test case to clean up after the test. Tape Library implementations MAY not perform this step. ***** This statement is followed by test cases that are not separated from each other or have the ""custom attributes"" or goal of each test described. Every test case should be separated from every other test cases and have the conditions and goal of the test described in prose. This applies to all the test cases in the listed versions.",,,Separate each test case from others and describe its inputs/outputs and/or conditions in prose., Technical Advisory Board,TAB-969 ,Hanging Paragraphs (5),Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 11:04 AM,20/Mar/14 11:04 AM,20/Mar/14 11:04 AM,,KMIP Tape Library Profile Version 1.0,,,,1,,,,,Style,"Sections 1 and 1.1 illustrate the issue with hanging paragraphs. If I say see Section 1, do I mean the two paragraphs following section 1 or do I mean that + 1.1 - 1.3? Hanging paragraphs in this draft are: 1, 1.1 2, 2.1 3, 3.1 3.1, 3.1.1 4.2, 4.2.1",,,Re-section the draft to remove hanging paragraphs, Technical Advisory Board,TAB-968 ,Repetition of Appendix B?,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 10:55 AM,20/Mar/14 10:55 AM,20/Mar/14 10:55 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"Unless I am mistaken, Appendix B. KMIP Specification Cross Reference appears in all of the profiles. At the same time, all of the profiles make reference to KMIP-SPEC, where Appendix B also occurs. That is in order to use any of the profiles, the reader must also have a copy of KMIP-SPEC. In the PDF versions, that adds another five (5) pages to each profile. Or a total of 45 pages of duplicated materials, which if printed, are likely to be discarded.",,,Suggest deletion of Appendix B in all profiles in favor of the mapping which already appears in KMIP-SPEC., Technical Advisory Board,TAB-966 ,Test Cases - violation of DRY?,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,20/Mar/14 10:15 AM,21/Mar/14 9:12 AM,20/Mar/14 10:22 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"After reading over my prior comments on test cases and reviewing the test cases in the drafts, it occurred to me that the test cases follow what is already a normative statement of requirements for each profile. Yes? Taking Tape Profile 1.0 as an example, 2 Tape Library Profile defines all the normative requirements for that profile. Yes? That is to say that if I do everything in 2 Tape Library Profile, I will be conforming to that profile of KMIP-SPEC. Yes? If that's the case, the the test cases violate DRY - Don't Repeat Yourself and are unnecessary. You have said all you need to say. Why say more? I still think the test cases are valuable but would put them in a non-normative document.",,,"Move all test cases to a non-normative document and allow normative requirements to stand by themselves, without repetition.", Technical Advisory Board,TAB-962 ,Suggestion for a normative interpretation of Test Cases,Improvement,New,Major,Unresolved,Unassigned,Jacques Durand,19/Mar/14 9:37 PM,,19/Mar/14 10:33 PM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0",,Public reviews,,1,,,,,Normative,"Suggestion for a normative interpretation of Test Cases: Since many KMIP profiles are specified in terms of ""test cases"", a normative interpretation should be given for these test cases. This could be done as a set of rules, that determine what the ""response"" should look like based on the ""Request"" message (assuming the implementation under test, i.e. the conformance target, is the one producing the response). These rules would be generic as much as possible (apply to all test cases in a profile at least). These rules can look like:. 1. Schema rule(s): when receiving a Request that satisfies [XML?] schema X, the implementation MUST send back a response that satisfies [XML?] schema Y. 2. Error rule(s): when receiving a Request that is incorrect (for various reasons) , the implementation MUST (or SHOULD?) send back a response that is of the form.... 3. Processing scope rules: they state what kind of Request content variations (both in terms of atomic values and optional elements) an implementation MUST accept (i.e. process and return something else than an Error). 4. Content dependency rules: these would capture several of the ""test case variation"" response cases, but establish a clear dependency rule with similar or related content in the Request.(i.e. how the Request content determines the Response content) 5. Independent variation rules: hese would restate several of the ""test case variation"" cases, that are independent from the Request content or the dependency of which is not easily expressed nor obvious. But maybe a range of resulting values can be stated. Such normative rules would be part of the specification body, but referred by the COnformance clause. With such rules, the Conformance Clause (for related implementation ) can say: ""[KMIP server] when receiving a Request matching any of the Mandatory test Cases (where ""matching"" allows variations as stated by rules X,Y,Z) , the [server] MUST generate a Response that satisfies the rules 1,2,3,4,5. when applied to the test case response."" instead of: ""support all Mandatory Test Cases (3.1and 3.2 and 3.3), for each supported protocol version (major and minor), returning results in accordance with the test cases."" Note you can then remove the confusingly vague statement: ""Note: the values for the returned items and the custom attributes are illustrative. Actual values from a real client system will vary. "" As this variability would be now defined by normative ""rules"". You can then state that all these test cases (along with their usage or variation rules) are normative content.",,,, Technical Advisory Board,TAB-934 ,Citations without section numbers,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 5:30 PM,20/Mar/14 10:03 AM,20/Mar/14 10:02 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, Key Management Interoperability Protocol Usage Guide Version 1.2, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"Just by way of example, 2.2 Suite B minLOS_128 (KMIP Suite B Profile Version 1.0) reads in part: ***** SHALL conform to the Baseline Server profile in [KMIP-PROF] and [KMIP-SPEC] and SHALL support the following Objects [KMIP-SPEC] Certificate [KMIP-SPEC] Symmetric Key [KMIP-SPEC] Public Key [KMIP-SPEC] Private Key [KMIP-SPEC] ***** Citations should include specific section numbers and titles in the cited document. I say that for two reasons: 1) The expert reader (members of this TC) are more likely to recognize an incorrect section citation by its title than by either [KMIP-SPEC] or [KMIP-SPEC:2.2.3]. Say for example if the citation were incorrect and read: [KMIP-SPEC:2.2.7], even an expert reader would be hard pressed to spot that error. On the other hand, if it read: ""Public Key [KMIP-SPEC:2.2.7 Secret Data]"" a TC member would know that wasn't the correct citation. 2) Assuming that all KMIP references between parts of this specification are written KMIP-(key):(number) (title), then it will be possible to automatically validate all of those references. For example, for KMIP-SPEC (the main document), all the section numbers and titles could be automatically extracted and then applied to a document with references to the KMIP-SPEC. By ""applied"" I mean compared to the citations in the text. Where it matches, nothing happens, but, where for whatever reason there is a KMIP cite that does not match, it is highlighted in red (for example). Proofing all the citations, at least to KMIP work, becomes a process of simply scrolling through the document looking for highlights. That won't help if the section citation is correct but substantively incorrect but only a human reader could catch that sort of error. The scripting, assuming reformation of the citations, would not take long and the actual running of the script against all the files would take less than 10 minutes. If not less. I note the work that went into Appendix B and if that effort is to be made on behalf of old users, it is much more necessary for new users of your latest work.",,,"Insert section numbers and titles for all citations of references, thus c. Public Key [KMIP-SPEC:2.2.3 Public Key] noting that ""public key"" appears all over KMIP-SPEC. The section reference makes it clear what is being referenced.", Technical Advisory Board,TAB-896 ,Obsoleted Reference,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:12 AM,,18/Mar/14 11:12 AM,,KMIP Tape Library Profile Version 1.0,,,,1,,,,,Normative,"1.2 Normative References reads in part: [RFC2246] T. Dierks and C. Allen, The TLS Protocol, Version 1.0, IETF RFC 2246, Jan 1999, http://www.ietf.org/rfc/rfc2246.txt The RFC editor's list at: http://www.rfc-editor.org/in-notes/rfc-ref.txt shows RFC2246 as superseded by RFC4346, which was itself superseded by RFC5246, which should be cited as: [RFC5246] Dierks, T. and E. Rescorla, ""The Transport Layer Security (TLS) Protocol Version 1.2"", RFC 5246, August 2008. http://www.ietf.org/rfc/rfc5246.txt Superseded references should not be cited in current work. Suggest updating the reference. On the other hand, since RFC2246 is not cited in this draft, you probably should just delete it.",,,Update the reference and/or simply delete., Technical Advisory Board,TAB-895 ,Keyword mis-use,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:10 AM,,18/Mar/14 11:10 AM,,KMIP Tape Library Profile Version 1.0,,,,1,,,,,Normative,"2.3 Using Application Specific Information for Key Identifiers: ""KMIP clients are NOT required to use Application Specific Information [KMIP-SPEC] however KMIP servers are required to support KMIP clients that use Application Specific Information [KMIP-SPEC] and KMIP clients that do not use Application Specific Information [KMIP-SPEC]."" ""NOT"" is not a keyword, at least not by itself.",,,"If this was meant to be a keyword, correct as per RFC 2119. Otherwise, use lowercase ""not.""", Technical Advisory Board,TAB-894 ,Note - need to be distinct,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:09 AM,,18/Mar/14 11:09 AM,,KMIP Tape Library Profile Version 1.0,,,,1,,,,,Normative,"2.3 reads in part: ""Note: the values for the returned items and the Custom Attributes are illustrative. Actual values from a real client system will vary."" Notes need to be typographically distinct and are non-normative. Use an indented style and declare all notes as non-normative.",,,Correct presentation of notes and declare to be non-normative., Technical Advisory Board,TAB-893 ,Test Cases - Structure,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:06 AM,19/Mar/14 8:20 PM,18/Mar/14 11:06 AM,,KMIP Tape Library Profile Version 1.0,,,,1,,,,,Normative,"From Key Management Interoperability Protocol Test Cases Version 1.2 1 Introduction reads: ""The purpose of this document is to describe test cases to demonstrate the Key Management Interoperability Protocol (KMIP) [KMIP-SPEC-1_2], [KMIP-SPEC-1_1], and [KMIP-SPEC-1_0]. The test cases illustrate that the concepts within the protocol are sound and how the protocol may be used when implementing KMIP in applications. These test cases are not intended to fully test an implementation of KMIP. There are test cases for v1.0, v1.1 and v1.2 of the protocol."" And 2 KMIP Test Cases reads in part: ""The test cases show one possible way to construct the messages, and the messages shown are not necessarily the only conformant constructions as many items within KMIP are optional and server behavior depends on the server's policy. Support for a test case is predicated on a server matching the test case assumptions and the behavior shown in the request-response pairs."" If that is true for KMIP 1.2, it is certainly also true for KMIP Tape Library Profile Version 1.0. A more useful location for the test cases would be in Key Management Interoperability Protocol Test Cases Version 1.2 and for the conformance clauses of Tape Profile to be written without reference to test cases. Which as noted above, doesn't really test all of a standard.",,,"Move test cases to Key Management Interoperability Protocol Test Cases Version 1.2, reform conformance clauses to not depend on test cases.", Technical Advisory Board,TAB-892 ,Test Cases - Normative vs. Non-Normative,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 11:01 AM,,18/Mar/14 11:01 AM,,KMIP Tape Library Profile Version 1.0,,,,1,,,,,Normative,"The Note in 2.3 reads in part: ""the values for the returned items and the Custom Attributes are illustrative. Actual values from a real client system will vary."" If the test cases are normative, then the responses are not and should be so marked. If the test cases are non-normative, then all should be marked as non-normative.",,,Mark all or part of use cases as non-normative as appropriate, Technical Advisory Board,TAB-891 ,Test Cases - No reference for type constraints,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:59 AM,,18/Mar/14 10:59 AM,,KMIP Tape Library Profile Version 1.0,,,,1,,,,,Technical,"The test cases that appear in XML markup contain attribute value restrictions. However, there is no normative citation of value definitions nor is there a schema to enforce those definitions, if given.",,,Normative citation of XML Schema Part 2 plus an XML schema for the test cases as defined are required at a minimum. Usefulness for users also requires the test cases in machine readable XML format., Technical Advisory Board,TAB-890 ,Normative versus Non-Normative text,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,18/Mar/14 10:45 AM,,18/Mar/14 10:45 AM,,KMIP Tape Library Profile Version 1.0,,,,1,,,,,Normative,"No statement of normative versus non-normative text. Which leads to failure to distinguish normative text from non-normative text. Some parts of 2.3 Using Application Specific Information for Key Identifiers: appear to be non-normative comparisons with other parts of KMIP and the last sentence of that section reads: ""Refer to [KMIP-UG] for further non-normative details of conversion to and from KAD values."" I assume from that there is a mixture of normative and non-normative content in 2.3. 2.4 Using Alternative Name for tape media barcode reads in part: ""Refer to [KMIP-UG-1_2] for further non-normative details of Alternative Name [KMIP-SPEC-1_2] usage."" One assumes that under 3 Tape Library Profile Test Cases that values of the returned items and the Custom Attributes are non-normative? Or as the draft says: ""Note: the values for the returned items and the Custom Attributes are illustrative. Actual values from a real client system will vary.""",,,"Mark sections as normative vs. non-normative or state at the outset that introductions, notes, examples, etc. are all non-normative.", Technical Advisory Board,TAB-785 ,Link Redirects 8,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,24/Feb/14 9:44 AM,,24/Feb/14 9:44 AM,,KMIP Tape Library Profile Version 1.0,,Public reviews,,0,,,,,Style,"The link checker at: http://validator.w3.org/checklink reports 8 redirects as follows: ***** Line: 1019 http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip redirected to https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 959 http://www.emc.com/ redirected to http://www.emc.com/index.htm Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Lines: 951, 1022 http://www.oasis-open.org/committees/kmip/ redirected to https://www.oasis-open.org/committees/kmip/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1115 http://www.oasis-open.org/ redirected to https://www.oasis-open.org/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1120 http://www.oasis-open.org/policies-guidelines/trademark redirected to https://www.oasis-open.org/policies-guidelines/trademark Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 964 http://www.netapp.com/ redirected to http://www.netapp.com/us/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1027 http://www.oasis-open.org/committees/kmip/ipr.php redirected to https://www.oasis-open.org/committees/kmip/ipr.php Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1059 http://www.oasis-open.org/policies-guidelines/ipr redirected to https://www.oasis-open.org/policies-guidelines/ipr Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. *****",,,Update the redirects to their present links., Technical Advisory Board,TAB-784 ,Broken HTML links,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,24/Feb/14 9:41 AM,,24/Feb/14 9:41 AM,,KMIP Tape Library Profile Version 1.0,,Public reviews,,0,,,,,Style,"1.3 Non-Normative References reads in part: ***** [KMIP-UG-1_0] Key Management Interoperability Protocol Usage Guide Version 1.0. http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc Committee Note Draft, 1 December 2011 [KMIP-UG-1_1] Key Management Interoperability Protocol Usage Guide Version 1.1. http://docs.oasis-open.org/kmip/ug/v1.1/cn01/kmip-ug-v1.1-cn01.doc Committee Note 01, 27 July 2012 [KMIP-UG-1_2] Key Management Interoperability Protocol Usage Guide Version 1.2. URL (has a bad hidden link) ***** The link checker at: http://validator.w3.org/checklink reports: ***** Lines: 1437, 1454 http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1-cnd01.doc Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. error Line: 1470 http://docs.oasis-open.org/kmip/usecases/v1.1/kmip-usecases-v1.1-cnd01.doc Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. ***** I grouped these together because they are references to other parts of your specification but also because there appears to be file naming confusion on the first two links. That is your text reports *identical* version numbers for versions 1.0 and 1.1. I thought that would be clearer if you check both links together. The unseen but broken link is just an error but it needs to be checked before the final version.",,,Check file names and correct links as appropriate., Generated at Fri Mar 21 13:20:51 UTC 2014 by Patrick Durusau using JIRA 6.1.1#6155-sha1:7188aeec9a6b57d61ea04c52f235f15f55c105e2.,,,,,,,,,,,,,,,,,,,,,,,,,,,
,,,,,,,,,,,,,,,,,,,,,,,,,,, OASIS Technical Committees Issue Tracker ,,,,,,,,,,,,,,,,,,,,,,,,,,, Displaying 2 issues at 21/Mar/14 9:43 AM.,,,,,,,,,,,,,,,,,,,,,,,,,,, Project,Key,Summary,Issue Type,Status,Priority,Resolution,Assignee,Reporter,Created,Last Viewed,Updated,Resolved,Affects Version/s,Fix Version/s,Component/s,Due Date,Watchers,Images,Work Ratio,Sub-Tasks,Linked Issues,Environment,Description,Security Level,Labels,Proposal,Resolution Technical Advisory Board,TAB-807 ,Link Redirects 6,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,25/Feb/14 10:47 AM,21/Mar/14 9:43 AM,25/Feb/14 10:47 AM,,Key Management Interoperability Protocol Test Cases Version 1.2,,Public reviews,,0,,,,,Style,"The link checker at: http://validator.w3.org/checklink reports 6 link redirects as follows: ***** Line: 992 http://www.thales-esecurity.com/ redirected to https://www.thales-esecurity.com/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1049 http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip redirected to https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 978 http://www.emc.com/ redirected to http://www.emc.com/index.htm Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Lines: 970, 1051 http://www.oasis-open.org/committees/kmip/ redirected to https://www.oasis-open.org/committees/kmip/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 983 http://www.netapp.com/ redirected to http://www.netapp.com/us/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 1077 http://www.oasis-open.org/policies-guidelines/ipr redirected to https://www.oasis-open.org/policies-guidelines/ipr Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. *****",,,Update links to their exact URLs., Technical Advisory Board,TAB-806 ,Broken HTML Links,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,25/Feb/14 10:45 AM,,25/Feb/14 10:45 AM,,Key Management Interoperability Protocol Test Cases Version 1.2,,Public reviews,,0,,,,,References,"1.1 References (non-normative) reads in part: ***** [KMIP-SPEC-1_1] Key Management Interoperability Protocol Usage Guide Version 1.1. 01 December 2011. OASIS Standard. http://docs.oasis-open.org/kmip/spec/v1.1/cd01/kmip-spec-1.1-cd-01.doc [KMIP-SPEC-1_2] Key Management Interoperability Protocol Usage Guide Version 1.2. DDD MMM YYYY. Candidate OASIS Standard 01. URL [KMIP-ENCODINGS] KMIP Additional Message Encodings Version 1.0. DDD MMM YYYY. Candidate OASIS Standard 01. URL ***** The link checker at: http://validator.w3.org/checklink reports as follows: ***** Lines: 1731, 1738, 1745 http://docs.oasis-open.org/kmip/spec/v1.1/cd01/kmip-spec-1.1-cd-01.doc Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. Broken fragments: http://docs.oasis-open.org/kmip/spec/v1.1/cd01/kmip-spec-1.1-cd-01.doc#_blank (lines 1731, 1738, 1745) ***** The one visible link and the two URL placeholders are broken.",,,Update links to a valid URL., Generated at Fri Mar 21 13:43:27 UTC 2014 by Patrick Durusau using JIRA 6.1.1#6155-sha1:7188aeec9a6b57d61ea04c52f235f15f55c105e2.,,,,,,,,,,,,,,,,,,,,,,,,,,,
,,,,,,,,,,,,,,,,,,,,,,,,,,, OASIS Technical Committees Issue Tracker ,,,,,,,,,,,,,,,,,,,,,,,,,,, Displaying 3 issues at 21/Mar/14 9:41 AM.,,,,,,,,,,,,,,,,,,,,,,,,,,, Project,Key,Summary,Issue Type,Status,Priority,Resolution,Assignee,Reporter,Created,Last Viewed,Updated,Resolved,Affects Version/s,Fix Version/s,Component/s,Due Date,Watchers,Images,Work Ratio,Sub-Tasks,Linked Issues,Environment,Description,Security Level,Labels,Proposal,Resolution Technical Advisory Board,TAB-934 ,Citations without section numbers,Bug,New,Major,Unresolved,Unassigned,Patrick Durusau,19/Mar/14 5:30 PM,21/Mar/14 9:41 AM,20/Mar/14 10:02 AM,,"KMIP Tape Library Profile Version 1.0, KMIP Symmetric Key Lifecycle Profile Version 1.0, KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0, KMIP Suite B Profile Version 1.0, KMIP Storage Array with Self-Encrypting Drives Profile Version 1.0, KMIP Opaque Managed Object Store Profile Version 1.0, KMIP Cryptographic Services Profile Version 1.0, KMIP Asymmetric Key Lifecycle Profile Version 1.0, Key Management Interoperability Protocol Usage Guide Version 1.2, KMIP Additional Message Encodings Version 1.0",,,,1,,,,,Style,"Just by way of example, 2.2 Suite B minLOS_128 (KMIP Suite B Profile Version 1.0) reads in part: ***** SHALL conform to the Baseline Server profile in [KMIP-PROF] and [KMIP-SPEC] and SHALL support the following Objects [KMIP-SPEC] Certificate [KMIP-SPEC] Symmetric Key [KMIP-SPEC] Public Key [KMIP-SPEC] Private Key [KMIP-SPEC] ***** Citations should include specific section numbers and titles in the cited document. I say that for two reasons: 1) The expert reader (members of this TC) are more likely to recognize an incorrect section citation by its title than by either [KMIP-SPEC] or [KMIP-SPEC:2.2.3]. Say for example if the citation were incorrect and read: [KMIP-SPEC:2.2.7], even an expert reader would be hard pressed to spot that error. On the other hand, if it read: ""Public Key [KMIP-SPEC:2.2.7 Secret Data]"" a TC member would know that wasn't the correct citation. 2) Assuming that all KMIP references between parts of this specification are written KMIP-(key):(number) (title), then it will be possible to automatically validate all of those references. For example, for KMIP-SPEC (the main document), all the section numbers and titles could be automatically extracted and then applied to a document with references to the KMIP-SPEC. By ""applied"" I mean compared to the citations in the text. Where it matches, nothing happens, but, where for whatever reason there is a KMIP cite that does not match, it is highlighted in red (for example). Proofing all the citations, at least to KMIP work, becomes a process of simply scrolling through the document looking for highlights. That won't help if the section citation is correct but substantively incorrect but only a human reader could catch that sort of error. The scripting, assuming reformation of the citations, would not take long and the actual running of the script against all the files would take less than 10 minutes. If not less. I note the work that went into Appendix B and if that effort is to be made on behalf of old users, it is much more necessary for new users of your latest work.",,,"Insert section numbers and titles for all citations of references, thus c. Public Key [KMIP-SPEC:2.2.3 Public Key] noting that ""public key"" appears all over KMIP-SPEC. The section reference makes it clear what is being referenced.", Technical Advisory Board,TAB-805 ,Link Redirects 8,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,25/Feb/14 10:38 AM,,25/Feb/14 10:38 AM,,Key Management Interoperability Protocol Usage Guide Version 1.2,,Public reviews,,0,,,,,Style,"The link checker at: http://validator.w3.org/checklink reports 8 link redirects as follows: ***** Line: 3709 http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip redirected to https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Lines: 3608, 3622 http://www.emc.com/ redirected to http://www.emc.com/index.htm Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 4327 http://www.rsa.com/rsalabs/node.asp?id=2125 redirected to http://www.emc.com/domains/rsa/index.htm?id=2125 Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 4334 http://www.rsa.com/rsalabs/node.asp?id=2132 redirected to http://www.emc.com/domains/rsa/index.htm?id=2132 Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Lines: 3600, 3712 http://www.oasis-open.org/committees/kmip/ redirected to https://www.oasis-open.org/committees/kmip/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 4493 http://www.itu.int/rec/recommendation.asp?lang=en&parent=T-REC-X.509-200811-I redirected to http://www.itu.int/rec/T-REC-X.509-200811-I/en Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 3613 http://www.netapp.com/ redirected to http://www.netapp.com/us/ Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. warning Line: 3742 http://www.oasis-open.org/policies-guidelines/ipr redirected to https://www.oasis-open.org/policies-guidelines/ipr Status: 301 -> 200 OK This is a permanent redirect. The link should be updated. *****",,,Update links to their exact URLs., Technical Advisory Board,TAB-804 ,Broken HTML Link,Bug,New,Minor,Unresolved,Unassigned,Patrick Durusau,25/Feb/14 10:36 AM,,25/Feb/14 10:36 AM,,Key Management Interoperability Protocol Usage Guide Version 1.2,,Public reviews,,0,,,,,References,"1.1 References (Normative) reads in part: ***** [FIPS186-4] Digital Signature Standard (DSS). FIPS PUB 186-4. July 2013. http://csrc.nist.gov/publications/fips/fips186-3/fips_186-4.pdf ***** The link checker at: http://validator.w3.org/checklink reports: ***** Line: 4278 http://csrc.nist.gov/publications/fips/fips186-3/fips_186-4.pdf Status: 404 Not Found The link is broken. Double-check that you have not made any typo, or mistake in copy-pasting. If the link points to a resource that no longer exists, you may want to remove or fix the link. ***** The URL I found for this document is: http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf",,,Update the link., Generated at Fri Mar 21 13:41:17 UTC 2014 by Patrick Durusau using JIRA 6.1.1#6155-sha1:7188aeec9a6b57d61ea04c52f235f15f55c105e2.,,,,,,,,,,,,,,,,,,,,,,,,,,,
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]