cti-taxii — archive

TAXII Conformance - proposed language

From: Patrick Durusau <[email protected]>
To: [email protected]
Date: Tue, 14 Jul 2015 18:20:00 -0000

Mark, On the conformance clause issue, just so we have a common starting point, the TC Process requires: ***** A specification that is approved by the TC at the Committee Specification Public Review Draft, Committee Specification or OASIS Standard level must include a separate section, listing a set of numbered conformance clauses, to which any implementation of the specification must adhere in order to claim conformance to the specification (or any optional portion thereof). ***** The conformance clauses as proposed don't meet the requirement of being numbered nor do they state any basis for conformance to those clauses. See elsewhere isn't a conformance clause. I wasn't a party to drafting that requirement but I suspect there were two main reasons for that language: 1) To provide the best chance that implementers will read the same requirements for conformance to all or part of a specification. To say: ***** Conformant implementations must conform to all Normative Statements that apply to the portions of TAXII they implement ***** leaves implementers at the mercy of hoping that all other implementers read the portions of TAXII the same way. Contrast that with sets of conformance clauses that enumerate the portions of TAXII (I assume that means conformance targets) and under each target lists numbered clauses that state the conformance requirements. Each set of conformance clauses would identify some portion, such as Discovery Service and so I could be assured that anyone saying they conform to Discovery Service, do in fact conform to the enumerated clauses. 2) For procurement purposes, of governments or enterprises, both of who are very interested in security products, the enumerated and numbered conformance clauses provide the means to specify the capabilities or characteristics that are desired for a particular project. It would look odd in a RFP to say: applications that conform to all the normative statements for Discovery Service in TAXII. Yes? 3) Ease of reference can be increased by well written, numbered conformance clauses. For example, you can page after page of prose when all you really wanted to check was: MUST conform to Extensible Markup Language (XML) 1.0 (Fifth Edition). 4) My personal hobby horse is that well written conformance clauses reduce the need for oddly worded prose and replace it with statements of fact. The datatype of attribute X is (insert content). You can say The datatype of attribute X MUST be (insert content). but that reads oddly. The bulk of the standard becomes a series of factual declarations and you can move all the RFC terms into the conformance clauses. Which gives you a much smaller surface to check for proper usage of RFC terms. Those are some of the general issues with the conformance clauses that obtain without looking at the specific standard content in question. Oh, one closing example, an implementer can't discover from the proposed conformance clauses, what other portions of TAXII exist, much less what their conformance requirements might be. True, they can labor through the document to discover them, maybe, but the question there is do you want to encourage implementation of TAXII or do you want to make it onerous? Hope you are having a great day! Patrick On 07/14/2015 08:51 AM, Davidson II, Mark S wrote: The Conformance section was written with that guidance in mind. In fact, the Conformance Guidelines were extremely helpful (I have no prior experience writing OASIS Conformance Clauses). Based on what I know (and please recognize that I’m new at this) I think the conformance clause, as written, functions as intended. I’m not sure whether to take the list’s silence as acceptance or not, but if there are no comments the conformance clause will likely go in pretty close to as-is. If there are specific comments that those more experienced can offer, I’m more than happy to hear them. I recognize part of making those comments requires understanding TAXII, and I can help with that. Thank you. -Mark From: [email protected] [ mailto:[email protected] ] On Behalf Of Chet Ensign Sent: Monday, July 13, 2015 1:47 PM To: Jordan, Bret Cc: Davidson II, Mark S; [email protected] ; OASIS TAB Subject: Re: [cti-taxii] TAXII Conformance - proposed language Hi Bret - Sure. I'm not suggesting any substantive change to the specification at all. Just suggesting that the conformance clause language be thought through from the perspective that I described. A conformance clause section is a requirement so I'm just suggesting making sure it does what it is intended to do. /chet On Mon, Jul 13, 2015 at 1:38 PM, Jordan, Bret < [email protected] > wrote: Chet, IMO, that would represent something we would do in TAXII 2.0 as we lock down the protocol to more of single implementation. This initial version, from the statement of the CTI Charter is to be just an OASIS version of the MITRE specification that is already in wide use today. If we make substantive changes, it will be in violation of the charter. And most of the TAXII specification is optional today. For example there is no hard and fast rule that requires you to use HTTP or XML. Intact, we have several groups using JSON based TAXII today. Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg. On Jul 13, 2015, at 08:55, Chet Ensign < [email protected] > wrote: Hi Mark & all - I have copied the OASIS TAB (Technical Advisory Board) on my reply as the group has done a lot of work (and continues to do a lot of work) on helping TCs craft conformance clauses. The TAB maintains a document with guidelines on how to draft conformance clauses that may be useful here: http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html You might want to talk with them a bit and consider spelling out conformance clauses in a bit more detail. Here's why: the conformance clauses are intended to act as a litmus test - a set of yes/no questions if you will - that an implementer can check off in order to know whether or not they can claim conformance to the Committee Specification / OASIS Standard. That is important because the OASIS patent protections specifically apply to conforming implementations. As you say, the clauses do not change in any way the requirements in the specification. They simply act as the checklist for conforming implementations. So that is the way I would think about them. Best, /chet On Mon, Jul 13, 2015 at 8:23 AM, Davidson II, Mark S < [email protected] > wrote: All, As Bret and I work toward converting TAXII into a set of OASIS documents, we came across the OASIS requirement for a conformance section, which TAXII 1.1 does not have. One example of an OASIS conformance section is the Universal Business Language (UBL) specification [1]. TAXII 1.1 does not have a conformance section, and instead relies on RFC 2119 normative statements (e.g., statements containing MUST/SHOULD/MAY) throughout the document. The OASIS conformance section seems to be a mechanism for wrapping the many Normative Statements in a specification into a condensed set of higher level statements/requirements. Bret and I have drafted a proposal for the conformance section of the TAXII Services Specification. The goal of the proposed text is to meet the OASIS requirement for a conformance section without altering the requirements for TAXII. This text is not intended to add, modify, or remove any requirements from TAXII 1.1. If you feel this text might not meet that criteria, please speak up. Without further preamble, here is the proposed text. Your feedback is welcome. Conformance Implementations have discretion over which parts of TAXII they implement (e.g., Discovery Service). Conformant implementations must conform to all Normative Statements that apply to the portions of TAXII they implement (e.g., Implementers of the Discovery Service must conform to all Normative Statements regarding the Discovery Service). Conformant implementations are free to ignore Normative Statements that do not apply to the portions of TAXII they implement (e.g., Non-implementers of the Discovery Service are free to ignore all Normative Statements regarding the Discovery Service). The conformance section of this document is intentionally broad and attempts to reiterate what already exists in this document. The TAXII 1.1 Specifications, which this specification is based on, did not have a conformance section. Instead, the TAXII 1.1 Specifications relied on normative statements. TAXII 1.1.1 represents a minimal change from TAXII 1.1, and in that spirit no requirements have been added, modified, or removed by this section. Thank you. Mark and Bret [1] http://docs.oasis-open.org/ubl/os-UBL-2.1/UBL-2.1.html#S-CONFORMANCE -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393 -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393 -- Patrick Durusau [email protected] Technical Advisory Board, OASIS (TAB) OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau