Conformance Clauses in Name Only (other issues)

The conformance clause of STIX[TM] Version 1.2.1. Part 2: Common reads as follows:

*****
Implementations have discretion over which parts (components, properties, extensions, controlled vocabularies, etc.) of STIX they implement (e.g., Indicator/Suggested_COAs).

[1] Conformant implementations must conform to all normative structural specifications of the UML model or additional normative statements within this document that apply to the portions of STIX they implement (e.g., Implementers of the entire TTP component must conform to all normative structural specifications of the UML model or additional normative statements within this document regarding the TTP component).

[2] Conformant implementations are free to ignore normative structural specifications of the UML model or additional normative statements within this document that do not apply to the portions of STIX they implement (e.g., Non-implementers of any particular properties of the TTP component are free to ignore all normative structural specifications of the UML model or additional normative statements within this document regarding those properties of the TTP component).

The conformance section of this document is intentionally broad and attempts to reiterate what already exists in this document. The STIX 1.2 Specifications, which this specification is based on, did not have a conformance section. Instead, the STIX 1.2 Specifications relied on normative statements and the non-mandatory implementation of STIX profiles. STIX 1.2.1 represents a minimal change from STIX 1.2, and in that spirit no requirements have been added, modified, or removed by this section.
*****

The conformance clause of TAXII[™] Version 1.1.1. Part 2: Services reads as follows:

*****
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 text. TAXII 1.1.1 represents a minimal change from TAXII 1.1, and in that spirit no new requirements have been defined in this document.
*****

Those conformance clauses are representative of the "conformance" clauses in TAXII and STIX, all parts so take this comment as general to all parts of both.

I understand and appreciate the difficulty of the transposition from ad hoc conformance to fully specified conformance by enumeration. However, that is in fact what is required under the existing OASIS TC process, that is meaningfully enumerated conformance clauses.

As you may recall, I surfaced these concerns not with this comment but months ago.

I understand the need to preserve "conformance" of existing applications to existing TAXII and STIX work but the means for doing that is NOT to fashion conformance clauses in name only prose.

You would be no doubt disappointed if the TC process requirements for voting were subject to the whim and caprice of the TC Administrator. Having worked so long and hard, you would be visibly upset if suddenly a 90% approval vote was required to become an OASIS standard. The same is true if only 1% of the OASIS membership was required to vote for your work.

Standards organizations have, well, standards for how they conduct their work and that is part of what gives them credibility in the marketplace, as well as guaranteeing equal treatment of all their members.

Rather than proceeding with the current text as submitted for balloting, the TC should revert to its original text and citing the need to preserve the current investment in its prior work, petition the OASIS Board to create a PAS like process by which its original work, can be approved as such and even published as an OASIS Standard, provided that the TC undertakes to create a newer version of that work at OASIS. (I understand that to be the current intent of the TC and in fact it is already proceeding in that direction.) That would preserve your current implementations, preserve the original text, preserve the distinction between pre-OASIS texts and post-OASIS texts, and not require a nudge-nudge wink-wink process with regard to the OASIS TC process.

The TC members themselves would benefit from such a position as treating all members similarly situated the same is the groundwork for an open and transparent process.

There are numerous other issues with the texts as they stand but since they should be approved by a PAS-like process, I won't weary the TCs ears with comments on a non-OASIS process.