CTI STIX Subcommittee

STIX SC community, As we work to move over the existing STIX 1.2 language specification content into the STIX 1.2.1 language specification documents that are compliant with the OASIS document templates one of the challenges we face is deciding how best to handle the Conformance clause sections of the specification documents. By OASIS definition a conformance clause is: " A statement in the Conformance section of a specification that provides a high-level description of what is required for an artifact to conform. It, in turn, refers to other parts of the specification for details. A Conformance Clause must reference one or more Normative Statements, directly or indirectly, and may refer to another Conformance Clause." Such conformance clauses are not something we have had to explicitly deal with to date so it is something new for our community. On top of the novelty of conformance clauses in general we also need to consider the comprehensiveness and flexibility of STIX/CybOX, the diversity of potential use cases and the fact that these first releases in OASIS must be as minimal change as possible from the pre-OASIS versions. Because of these factors, complex and detailed conformance criteria tied to specific structures of the languages or protocols are not really practical. We need to find a way to achieve the intent of the conformance sections but do so in a more general and practical way. After reviewing the OASIS guidelines and examples on conformance clauses and taking a look at what Mark & Bret came up with for TAXII, we are proposing something very closely aligned to the TAXII approach with a few necessary tweaks for STIX. For the STIX 1.2.1 language specifications, we propose the following wording for the Conformance section: Conformance 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 Statements that apply to the portions of STIX they implement (e.g., Implementers of the entire TTP component must conform to all Normative Statements regarding the TTP component).   [2] Conformant implementations are free to ignore Normative Statements 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 Statements 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. In addition to this wording in the STIX 1.2.1 language-level multipart specification there will also be separate conformance wording within the STIX 1.2.1 XML Binding Specification (with accompanying XSD reference implementation). The conformance wording for the XML binding specification and any other binding specification (e.g. JSON) is likely to be more technical. We do recognize that the proposed clause #1 above lacks explicit specificity on exactly what portions of STIX are in-scope or out-of-scope for a given implementation. For this reason, we continue to strongly suggest the use of STIX Profiles to make such distinctions clear. We considered the option of proposing that they be required here in the conformance section but decided against it for STIX 1.2.1 due to the requirement for minimal change from 1.2 and due to the limitations with the current mechanism for capturing and conveying Profiles. It is believed that such a mandatory requirement will likely be necessary for STIX 2.0 to make widespread conformance assertion and assessment more practical. Because of this the limitations in the current profile mechanism will likely need to be addressed as part of the overall STIX 2.0 effort. What do you all think about spinning up a separate work product effort to look into the Profile representation and tooling issues? So, the net-net here is that we are looking for your concurrence or concerns on the above proposed wording. We need to include the wording in the specification drafts that are targeted for EOB Friday delivery so hearing from you within the next day or two is important. Don’t be too concerned if you cannot provide feedback that quickly. This wording is not yet case in stone. If we discover issues with it we can still tweak it as necessary as we review the drafts next week. Thank you for your consideration and thoughts on this matter. sean  

Just FYI on the approach that the Cyber Threat Intel STIX subcommittee is proposing for conformance clauses for their current draft. I'm happy to explain more on their thinking if you are interested. They are likely to revisit this when they start work on 2.0.  ---------- Forwarded message ---------- From: Barnum, Sean D. < sbarnum@mitre.org > Date: Mon, Aug 31, 2015 at 2:33 PM Subject: [cti-stix] Conformance clauses for the STIX specification documents To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > STIX SC community, As we work to move over the existing STIX 1.2 language specification content into the STIX 1.2.1 language specification documents that are compliant with the OASIS document templates one of the challenges we face is deciding how best to handle the Conformance clause sections of the specification documents. By OASIS definition a conformance clause is: " A statement in the Conformance section of a specification that provides a high-level description of what is required for an artifact to conform. It, in turn, refers to other parts of the specification for details. A Conformance Clause must reference one or more Normative Statements, directly or indirectly, and may refer to another Conformance Clause." Such conformance clauses are not something we have had to explicitly deal with to date so it is something new for our community. On top of the novelty of conformance clauses in general we also need to consider the comprehensiveness and flexibility of STIX/CybOX, the diversity of potential use cases and the fact that these first releases in OASIS must be as minimal change as possible from the pre-OASIS versions. Because of these factors, complex and detailed conformance criteria tied to specific structures of the languages or protocols are not really practical. We need to find a way to achieve the intent of the conformance sections but do so in a more general and practical way. After reviewing the OASIS guidelines and examples on conformance clauses and taking a look at what Mark & Bret came up with for TAXII, we are proposing something very closely aligned to the TAXII approach with a few necessary tweaks for STIX. For the STIX 1.2.1 language specifications, we propose the following wording for the Conformance section: Conformance 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 Statements that apply to the portions of STIX they implement (e.g., Implementers of the entire TTP component must conform to all Normative Statements regarding the TTP component).   [2] Conformant implementations are free to ignore Normative Statements 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 Statements 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. In addition to this wording in the STIX 1.2.1 language-level multipart specification there will also be separate conformance wording within the STIX 1.2.1 XML Binding Specification (with accompanying XSD reference implementation). The conformance wording for the XML binding specification and any other binding specification (e.g. JSON) is likely to be more technical. We do recognize that the proposed clause #1 above lacks explicit specificity on exactly what portions of STIX are in-scope or out-of-scope for a given implementation. For this reason, we continue to strongly suggest the use of STIX Profiles to make such distinctions clear. We considered the option of proposing that they be required here in the conformance section but decided against it for STIX 1.2.1 due to the requirement for minimal change from 1.2 and due to the limitations with the current mechanism for capturing and conveying Profiles. It is believed that such a mandatory requirement will likely be necessary for STIX 2.0 to make widespread conformance assertion and assessment more practical. Because of this the limitations in the current profile mechanism will likely need to be addressed as part of the overall STIX 2.0 effort. What do you all think about spinning up a separate work product effort to look into the Profile representation and tooling issues? So, the net-net here is that we are looking for your concurrence or concerns on the above proposed wording. We need to include the wording in the specification drafts that are targeted for EOB Friday delivery so hearing from you within the next day or two is important. Don’t be too concerned if you cannot provide feedback that quickly. This wording is not yet case in stone. If we discover issues with it we can still tweak it as necessary as we review the drafts next week. Thank you for your consideration and thoughts on this matter. sean   -- /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, I find even the entertaining of such suggestions from the Cyber Threat Intel STIX TC disturbing. By their own admission: ***** Because of these factors, complex and detailed conformance criteria tied to specific structures of the languages or protocols are not really practical. ***** They have no intent whatsoever in following the TC process for conformance clauses. That's unfortunate because the OASIS Board and OASIS members have labored for years to produce a practical yet formal approach to standards making that meets the need to proceed without undue delay but also in a manner that produces interoperable implementations based on quality work. Rather than set an unfortunate precedent for others to attempt to follow, why not: 1. Have the TC formally adopt the existing versions in toto as TC work products and inputs into their work at OASIS. 2. As a result of formal adoption by the TC as TC work products, the TC Admin affixes an OASIS cover page, much like ISO does with a PAS submission, on the adopted work. 3. Probably need a designation: TC Adopted Work Product or some such to distinguish it from notes and specifications. But it can't advance without full conformance to the OASIS TC process. This seems to be a recurrent problem although I am hard pressed to say why changing work is such a surprise when people arrive at OASIS. A question that others need to explore. With the board meeting coming up in October, such a process, which would not involve public review cycles, etc. would both meet the immediate needs of the Cyber Threat Intel STIX TC and not penalize other OASIS members for having been so foolish as to follow the TC process in preparation of their work. The foregoing may sound harsh but kudos to the TC for admitting that they are not going to follow the TC process and its conformance clause requirements. Such honesty isn't common. Hope you are having a great day! Patrick PS: I am willing to draft a first cut at the TC Adopted Work Product addition to the TC Process if that would help. On 09/01/2015 09:56 AM, Chet Ensign wrote: Just FYI on the approach that the Cyber Threat Intel STIX subcommittee is proposing for conformance clauses for their current draft. I'm happy to explain more on their thinking if you are interested. They are likely to revisit this when they start work on 2.0.  ---------- Forwarded message ---------- From: Barnum, Sean D. < sbarnum@mitre.org > Date: Mon, Aug 31, 2015 at 2:33 PM Subject: [cti-stix] Conformance clauses for the STIX specification documents To: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > STIX SC community, As we work to move over the existing STIX 1.2 language specification content into the STIX 1.2.1 language specification documents that are compliant with the OASIS document templates one of the challenges we face is deciding how best to handle the Conformance clause sections of the specification documents. By OASIS definition a conformance clause is: A statement in the Conformance section of a specification that provides a high-level description of what is required for an artifact to conform. It, in turn, refers to other parts of the specification for details. A Conformance Clause must reference one or more Normative Statements, directly or indirectly, and may refer to another Conformance Clause. Such conformance clauses are not something we have had to explicitly deal with to date so it is something new for our community. On top of the novelty of conformance clauses in general we also need to consider the comprehensiveness and flexibility of STIX/CybOX, the diversity of potential use cases and the fact that these first releases in OASIS must be as minimal change as possible from the pre-OASIS versions. Because of these factors, complex and detailed conformance criteria tied to specific structures of the languages or protocols are not really practical. We need to find a way to achieve the intent of the conformance sections but do so in a more general and practical way. After reviewing the OASIS guidelines and examples on conformance clauses and taking a look at what Mark & Bret came up with for TAXII, we are proposing something very closely aligned to the TAXII approach with a few necessary tweaks for STIX. For the STIX 1.2.1 language specifications, we propose the following wording for the Conformance section: Conformance 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 Statements that apply to the portions of STIX they implement (e.g., Implementers of the entire TTP component must conform to all Normative Statements regarding the TTP component).   [2] Conformant implementations are free to ignore Normative Statements 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 Statements 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. In addition to this wording in the STIX 1.2.1 language-level multipart specification there will also be separate conformance wording within the STIX 1.2.1 XML Binding Specification (with accompanying XSD reference implementation). The conformance wording for the XML binding specification and any other binding specification (e.g. JSON) is likely to be more technical. We do recognize that the proposed clause #1 above lacks explicit specificity on exactly what portions of STIX are in-scope or out-of-scope for a given implementation. For this reason, we continue to strongly suggest the use of STIX Profiles to make such distinctions clear. We considered the option of proposing that they be required here in the conformance section but decided against it for STIX 1.2.1 due to the requirement for minimal change from 1.2 and due to the limitations with the current mechanism for capturing and conveying Profiles. It is believed that such a mandatory requirement will likely be necessary for STIX 2.0 to make widespread conformance assertion and assessment more practical. Because of this the limitations in the current profile mechanism will likely need to be addressed as part of the overall STIX 2.0 effort. What do you all think about spinning up a separate work product effort to look into the Profile representation and tooling issues? So, the net-net here is that we are looking for your concurrence or concerns on the above proposed wording. We need to include the wording in the specification drafts that are targeted for EOB Friday delivery so hearing from you within the next day or two is important. Don’t be too concerned if you cannot provide feedback that quickly. This wording is not yet case in stone. If we discover issues with it we can still tweak it as necessary as we review the drafts next week. Thank you for your consideration and thoughts on this matter. sean   -- /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 patrick@durusau.net 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

Chet, After reflecting some more on the problem facing the Cyber Threat Intel STIX TC, it may be possible to fashion a solution that both makes OASIS more inviting to already mature communities as well as quickening the time required to produce a sameAs version of mature work for the TC. Building on what I mentioned as an aside on the ISO PAS process, what if: 1) TCs that want to have mature work, developed outside of OASIS, approved by both a TC and OASIS, be required to have higher organizational membership that ordinary OASIS TCs. Thinking that OASIS wants to become the home of mature communities that already have a vibrant community, as reflected in a larger than usual number of organizational members as part of the TC. (You would have to run the numbers to see what a higher than usual number would be.) 2) Such TCs would include with their charters, statements of use of the mature work by X percent of their higher than usual number of organizational members, which forms the basis for adoption of the existing work, as-is, but with an appropriate OASIS cover page. 3) First stage is that the TC adopts the mature work by a seven day electronic ballot. 4) Second stage, the adopted work is given an appropriate cover page and posted by the TC Admin. 5) Third stage, upon request of the TC, just an ordinary vote, the TC Admin creates a sixty day ballot period on the now TC adopted mature work for adoption as an OASIS Standard, whose cover page recites the origin of the mature work. 6) Voting might need a higher percentage of organizational members, just so this doesn't become a way around the OASIS TC process. But this also drives the mature community idea that benefits OASIS. This is adoption of a mature community by OASIS and not a growing a community by OASIS. The latter is already handled by the normal OASIS process. Except for the percentages, etc., I don't see anything tricky about such a process and it would facilitate the adoption of mature work prepared elsewhere when migrating mature communities to OASIS. As before, I am willing to draft the appropriate language if that would be helpful. Hope you are having a great day! Patrick On 09/01/2015 12:09 PM, Patrick Durusau wrote: Chet, I find even the entertaining of such suggestions from the Cyber Threat Intel STIX TC disturbing. By their own admission: ***** Because of these factors, complex and detailed conformance criteria tied to specific structures of the languages or protocols are not really practical. ***** They have no intent whatsoever in following the TC process for conformance clauses. That's unfortunate because the OASIS Board and OASIS members have labored for years to produce a practical yet formal approach to standards making that meets the need to proceed without undue delay but also in a manner that produces interoperable implementations based on quality work. Rather than set an unfortunate precedent for others to attempt to follow, why not: 1. Have the TC formally adopt the existing versions in toto as TC work products and inputs into their work at OASIS. 2. As a result of formal adoption by the TC as TC work products, the TC Admin affixes an OASIS cover page, much like ISO does with a PAS submission, on the adopted work. 3. Probably need a designation: TC Adopted Work Product or some such to distinguish it from notes and specifications. But it can't advance without full conformance to the OASIS TC process. This seems to be a recurrent problem although I am hard pressed to say why changing work is such a surprise when people arrive at OASIS. A question that others need to explore. With the board meeting coming up in October, such a process, which would not involve public review cycles, etc. would both meet the immediate needs of the Cyber Threat Intel STIX TC and not penalize other OASIS members for having been so foolish as to follow the TC process in preparation of their work. The foregoing may sound harsh but kudos to the TC for admitting that they are not going to follow the TC process and its conformance clause requirements. Such honesty isn't common. Hope you are having a great day! Patrick PS: I am willing to draft a first cut at the TC Adopted Work Product addition to the TC Process if that would help. On 09/01/2015 09:56 AM, Chet Ensign wrote: Just FYI on the approach that the Cyber Threat Intel STIX subcommittee is proposing for conformance clauses for their current draft. I'm happy to explain more on their thinking if you are interested. They are likely to revisit this when they start work on 2.0.  ---------- Forwarded message ---------- From: Barnum, Sean D. < sbarnum@mitre.org > Date: Mon, Aug 31, 2015 at 2:33 PM Subject: [cti-stix] Conformance clauses for the STIX specification documents To: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > STIX SC community, As we work to move over the existing STIX 1.2 language specification content into the STIX 1.2.1 language specification documents that are compliant with the OASIS document templates one of the challenges we face is deciding how best to handle the Conformance clause sections of the specification documents. By OASIS definition a conformance clause is: A statement in the Conformance section of a specification that provides a high-level description of what is required for an artifact to conform. It, in turn, refers to other parts of the specification for details. A Conformance Clause must reference one or more Normative Statements, directly or indirectly, and may refer to another Conformance Clause. Such conformance clauses are not something we have had to explicitly deal with to date so it is something new for our community. On top of the novelty of conformance clauses in general we also need to consider the comprehensiveness and flexibility of STIX/CybOX, the diversity of potential use cases and the fact that these first releases in OASIS must be as minimal change as possible from the pre-OASIS versions. Because of these factors, complex and detailed conformance criteria tied to specific structures of the languages or protocols are not really practical. We need to find a way to achieve the intent of the conformance sections but do so in a more general and practical way. After reviewing the OASIS guidelines and examples on conformance clauses and taking a look at what Mark & Bret came up with for TAXII, we are proposing something very closely aligned to the TAXII approach with a few necessary tweaks for STIX. For the STIX 1.2.1 language specifications, we propose the following wording for the Conformance section: Conformance 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 Statements that apply to the portions of STIX they implement (e.g., Implementers of the entire TTP component must conform to all Normative Statements regarding the TTP component).   [2] Conformant implementations are free to ignore Normative Statements 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 Statements 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. In addition to this wording in the STIX 1.2.1 language-level multipart specification there will also be separate conformance wording within the STIX 1.2.1 XML Binding Specification (with accompanying XSD reference implementation). The conformance wording for the XML binding specification and any other binding specification (e.g. JSON) is likely to be more technical. We do recognize that the proposed clause #1 above lacks explicit specificity on exactly what portions of STIX are in-scope or out-of-scope for a given implementation. For this reason, we continue to strongly suggest the use of STIX Profiles to make such distinctions clear. We considered the option of proposing that they be required here in the conformance section but decided against it for STIX 1.2.1 due to the requirement for minimal change from 1.2 and due to the limitations with the current mechanism for capturing and conveying Profiles. It is believed that such a mandatory requirement will likely be necessary for STIX 2.0 to make widespread conformance assertion and assessment more practical. Because of this the limitations in the current profile mechanism will likely need to be addressed as part of the overall STIX 2.0 effort. What do you all think about spinning up a separate work product effort to look into the Profile representation and tooling issues? So, the net-net here is that we are looking for your concurrence or concerns on the above proposed wording. We need to include the wording in the specification drafts that are targeted for EOB Friday delivery so hearing from you within the next day or two is important. Don’t be too concerned if you cannot provide feedback that quickly. This wording is not yet case in stone. If we discover issues with it we can still tweak it as necessary as we review the drafts next week. Thank you for your consideration and thoughts on this matter. sean   -- /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 patrick@durusau.net 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 -- Patrick Durusau patrick@durusau.net 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

Hmm. Can I share this with Laurent? I could see a fit with the Consortium in a Box idea. It certainly would call for changes to the TC Process - but as you say, it might well draw some work to OASIS.  /c On Tue, Sep 1, 2015 at 3:54 PM, Patrick Durusau < patrick@durusau.net > wrote: Chet, After reflecting some more on the problem facing the Cyber Threat Intel STIX TC, it may be possible to fashion a solution that both makes OASIS more inviting to already mature communities as well as quickening the time required to produce a "sameAs" version of mature work for the TC. Building on what I mentioned as an aside on the ISO PAS process, what if: 1) TCs that want to have mature work, developed outside of OASIS, approved by both a TC and OASIS, be required to have higher organizational membership that ordinary OASIS TCs. Thinking that OASIS wants to become the home of mature communities that already have a vibrant community, as reflected in a larger than usual number of organizational members as part of the TC. (You would have to run the numbers to see what a higher than usual number would be.) 2) Such TCs would include with their charters, statements of use of the mature work by X percent of their higher than usual number of organizational members, which forms the basis for adoption of the existing work, as-is, but with an appropriate OASIS cover page. 3) First stage is that the TC adopts the mature work by a seven day electronic ballot. 4) Second stage, the adopted work is given an appropriate cover page and posted by the TC Admin. 5) Third stage, upon request of the TC, just an ordinary vote, the TC Admin creates a sixty day ballot period on the now TC adopted mature work for adoption as an OASIS Standard, whose cover page recites the origin of the mature work. 6) Voting might need a higher percentage of organizational members, just so this doesn't become a way around the OASIS TC process. But this also drives the mature community idea that benefits OASIS. This is adoption of a mature community by OASIS and not a growing a community by OASIS. The latter is already handled by the normal OASIS process. Except for the percentages, etc., I don't see anything tricky about such a process and it would facilitate the adoption of mature work prepared elsewhere when migrating mature communities to OASIS. As before, I am willing to draft the appropriate language if that would be helpful. Hope you are having a great day! Patrick On 09/01/2015 12:09 PM, Patrick Durusau wrote: Chet, I find even the entertaining of such suggestions from the Cyber Threat Intel STIX TC disturbing. By their own admission: ***** Because of these factors, complex and detailed conformance criteria tied to specific structures of the languages or protocols are not really practical. ***** They have no intent whatsoever in following the TC process for conformance clauses. That's unfortunate because the OASIS Board and OASIS members have labored for years to produce a practical yet formal approach to standards making that meets the need to proceed without undue delay but also in a manner that produces interoperable implementations based on quality work. Rather than set an unfortunate precedent for others to attempt to follow, why not: 1. Have the TC formally adopt the existing versions in toto as TC work products and inputs into their work at OASIS. 2. As a result of formal adoption by the TC as TC work products, the TC Admin affixes an OASIS cover page, much like ISO does with a PAS submission, on the adopted work. 3. Probably need a designation: TC Adopted Work Product or some such to distinguish it from notes and specifications. But it can't advance without full conformance to the OASIS TC process. This seems to be a recurrent problem although I am hard pressed to say why changing work is such a surprise when people arrive at OASIS. A question that others need to explore. With the board meeting coming up in October, such a process, which would not involve public review cycles, etc. would both meet the immediate needs of the Cyber Threat Intel STIX TC and not penalize other OASIS members for having been so foolish as to follow the TC process in preparation of their work. The foregoing may sound harsh but kudos to the TC for admitting that they are not going to follow the TC process and its conformance clause requirements. Such honesty isn't common. Hope you are having a great day! Patrick PS: I am willing to draft a first cut at the TC Adopted Work Product addition to the TC Process if that would help. On 09/01/2015 09:56 AM, Chet Ensign wrote: Just FYI on the approach that the Cyber Threat Intel STIX subcommittee is proposing for conformance clauses for their current draft. I'm happy to explain more on their thinking if you are interested. They are likely to revisit this when they start work on 2.0.  ---------- Forwarded message ---------- From: Barnum, Sean D. < sbarnum@mitre.org > Date: Mon, Aug 31, 2015 at 2:33 PM Subject: [cti-stix] Conformance clauses for the STIX specification documents To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > STIX SC community, As we work to move over the existing STIX 1.2 language specification content into the STIX 1.2.1 language specification documents that are compliant with the OASIS document templates one of the challenges we face is deciding how best to handle the Conformance clause sections of the specification documents. By OASIS definition a conformance clause is: " A statement in the Conformance section of a specification that provides a high-level description of what is required for an artifact to conform. It, in turn, refers to other parts of the specification for details. A Conformance Clause must reference one or more Normative Statements, directly or indirectly, and may refer to another Conformance Clause." Such conformance clauses are not something we have had to explicitly deal with to date so it is something new for our community. On top of the novelty of conformance clauses in general we also need to consider the comprehensiveness and flexibility of STIX/CybOX, the diversity of potential use cases and the fact that these first releases in OASIS must be as minimal change as possible from the pre-OASIS versions. Because of these factors, complex and detailed conformance criteria tied to specific structures of the languages or protocols are not really practical. We need to find a way to achieve the intent of the conformance sections but do so in a more general and practical way. After reviewing the OASIS guidelines and examples on conformance clauses and taking a look at what Mark & Bret came up with for TAXII, we are proposing something very closely aligned to the TAXII approach with a few necessary tweaks for STIX. For the STIX 1.2.1 language specifications, we propose the following wording for the Conformance section: Conformance 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 Statements that apply to the portions of STIX they implement (e.g., Implementers of the entire TTP component must conform to all Normative Statements regarding the TTP component).   [2] Conformant implementations are free to ignore Normative Statements 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 Statements 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. In addition to this wording in the STIX 1.2.1 language-level multipart specification there will also be separate conformance wording within the STIX 1.2.1 XML Binding Specification (with accompanying XSD reference implementation). The conformance wording for the XML binding specification and any other binding specification (e.g. JSON) is likely to be more technical. We do recognize that the proposed clause #1 above lacks explicit specificity on exactly what portions of STIX are in-scope or out-of-scope for a given implementation. For this reason, we continue to strongly suggest the use of STIX Profiles to make such distinctions clear. We considered the option of proposing that they be required here in the conformance section but decided against it for STIX 1.2.1 due to the requirement for minimal change from 1.2 and due to the limitations with the current mechanism for capturing and conveying Profiles. It is believed that such a mandatory requirement will likely be necessary for STIX 2.0 to make widespread conformance assertion and assessment more practical. Because of this the limitations in the current profile mechanism will likely need to be addressed as part of the overall STIX 2.0 effort. What do you all think about spinning up a separate work product effort to look into the Profile representation and tooling issues? So, the net-net here is that we are looking for your concurrence or concerns on the above proposed wording. We need to include the wording in the specification drafts that are targeted for EOB Friday delivery so hearing from you within the next day or two is important. Don’t be too concerned if you cannot provide feedback that quickly. This wording is not yet case in stone. If we discover issues with it we can still tweak it as necessary as we review the drafts next week. Thank you for your consideration and thoughts on this matter. sean   -- /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 patrick@durusau.net 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 -- Patrick Durusau patrick@durusau.net 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 -- /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 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chet, Sure, hope it proves to be of interest! Hope you are having a great day! Patrick On 01/15/2016 10:16 AM, Chet Ensign wrote: > Hmm. Can I share this with Laurent? I could see a fit with the > Consortium in a Box idea. It certainly would call for changes to > the TC Process - but as you say, it might well draw some work to > OASIS. > > /c > > On Tue, Sep 1, 2015 at 3:54 PM, Patrick Durusau > <patrick@durusau.net < mailto:patrick@durusau.net >> wrote: > > Chet, > > After reflecting some more on the problem facing the Cyber Threat > Intel STIX TC, it may be possible to fashion a solution that both > makes OASIS more inviting to already mature communities as well as > quickening the time required to produce a "sameAs" version of > mature work for the TC. > > Building on what I mentioned as an aside on the ISO PAS process, > what if: > > 1) TCs that want to have mature work, developed outside of OASIS, > approved by both a TC and OASIS, be required to have higher > organizational membership that ordinary OASIS TCs. > > Thinking that OASIS wants to become the home of mature communities > that already have a vibrant community, as reflected in a larger > than usual number of organizational members as part of the TC. (You > would have to run the numbers to see what a higher than usual > number would be.) > > 2) Such TCs would include with their charters, statements of use > of the mature work by X percent of their higher than usual number > of organizational members, which forms the basis for adoption of > the existing work, as-is, but with an appropriate OASIS cover > page. > > 3) First stage is that the TC adopts the mature work by a seven > day electronic ballot. > > 4) Second stage, the adopted work is given an appropriate cover > page and posted by the TC Admin. > > 5) Third stage, upon request of the TC, just an ordinary vote, the > TC Admin creates a sixty day ballot period on the now TC adopted > mature work for adoption as an OASIS Standard, whose cover page > recites the origin of the mature work. > > 6) Voting might need a higher percentage of organizational > members, just so this doesn't become a way around the OASIS TC > process. But this also drives the mature community idea that > benefits OASIS. > > This is adoption of a mature community by OASIS and not a growing > a community by OASIS. The latter is already handled by the normal > OASIS process. > > Except for the percentages, etc., I don't see anything tricky > about such a process and it would facilitate the adoption of mature > work prepared elsewhere when migrating mature communities to > OASIS. > > As before, I am willing to draft the appropriate language if that > would be helpful. > > Hope you are having a great day! > > Patrick > > > > On 09/01/2015 12:09 PM, Patrick Durusau wrote: >> Chet, >> >> I find even the entertaining of such suggestions from the Cyber >> Threat Intel STIX TC disturbing. >> >> By their own admission: >> >> ***** Because of these factors, complex and detailed conformance >> criteria tied to specific structures of the languages or >> protocols are not really practical. ***** >> >> They have no intent whatsoever in following the TC process for >> conformance clauses. >> >> That's unfortunate because the OASIS Board and OASIS members >> have labored for years to produce a practical yet formal approach >> to standards making that meets the need to proceed without undue >> delay but also in a manner that produces interoperable >> implementations based on quality work. >> >> Rather than set an unfortunate precedent for others to attempt >> to follow, why not: >> >> 1. Have the TC formally adopt the existing versions in toto as >> TC work products and inputs into their work at OASIS. >> >> 2. As a result of formal adoption by the TC as TC work products, >> the TC Admin affixes an OASIS cover page, much like ISO does >> with a PAS submission, on the adopted work. >> >> 3. Probably need a designation: TC Adopted Work Product or some >> such to distinguish it from notes and specifications. But it >> can't advance without full conformance to the OASIS TC process. >> >> This seems to be a recurrent problem although I am hard pressed >> to say why changing work is such a surprise when people arrive >> at OASIS. A question that others need to explore. >> >> With the board meeting coming up in October, such a process, >> which would not involve public review cycles, etc. would both >> meet the immediate needs of the Cyber Threat Intel STIX TC and >> not penalize other OASIS members for having been so foolish as to >> follow the TC process in preparation of their work. >> >> The foregoing may sound harsh but kudos to the TC for admitting >> that they are not going to follow the TC process and its >> conformance clause requirements. Such honesty isn't common. >> >> Hope you are having a great day! >> >> Patrick >> >> PS: I am willing to draft a first cut at the TC Adopted Work >> Product addition to the TC Process if that would help. >> >> >> On 09/01/2015 09:56 AM, Chet Ensign wrote: >>> Just FYI on the approach that the Cyber Threat Intel STIX >>> subcommittee is proposing for conformance clauses for their >>> current draft. I'm happy to explain more on their thinking if >>> you are interested. They are likely to revisit this when they >>> start work on 2.0. >>> >>> >>> ---------- Forwarded message ---------- From: *Barnum, Sean D.* >>> <sbarnum@mitre.org < mailto:sbarnum@mitre.org >> Date: Mon, Aug >>> 31, 2015 at 2:33 PM Subject: [cti-stix] Conformance clauses for >>> the STIX specification documents To: >>> "cti-stix@lists.oasis-open.org >>> < mailto:cti-stix@lists.oasis-open.org >" >>> <cti-stix@lists.oasis-open.org >>> < mailto:cti-stix@lists.oasis-open.org >> >>> >>> >>> STIX SC community, >>> >>> As we work to move over the existing STIX 1.2 language >>> specification content into the STIX 1.2.1 language >>> specification documents that are compliant with the OASIS >>> document templates one of the challenges we face is deciding >>> how best to handle the Conformance clause sections of the >>> specification documents. By OASIS definition a conformance >>> clause is: "A statement in the Conformance section of a >>> specification that provides a high-level description of what is >>> required for an artifact to conform. It, in turn, refers to >>> other parts of the specification for details. A Conformance >>> Clause must reference one or more Normative Statements, >>> directly or indirectly, and may refer to another Conformance >>> Clause." >>> >>> Such conformance clauses are not something we have had to >>> explicitly deal with to date so it is something new for our >>> community. On top of the novelty of conformance clauses in >>> general we also need to consider the comprehensiveness and >>> flexibility of STIX/CybOX, the diversity of potential use >>> cases and the fact that these first releases in OASIS must be >>> as minimal change as possible from the pre-OASIS versions. >>> >>> Because of these factors, complex and detailed conformance >>> criteria tied to specific structures of the languages or >>> protocols are not really practical. >>> >>> We need to find a way to achieve the intent of the conformance >>> sections but do so in a more general and practical way. >>> >>> After reviewing the OASIS guidelines and examples on >>> conformance clauses and taking a look at what Mark & Bret came >>> up with for TAXII, we are proposing something very closely >>> aligned to the TAXII approach with a few necessary tweaks for >>> STIX. >>> >>> >>> For the STIX 1.2.1 language specifications, we propose the >>> following wording for the Conformance section: >>> >>> >>> *Conformance* >>> >>> 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 >>> Statements that apply to the portions of STIX they implement >>> (e.g., Implementers of the entire TTP component must conform to >>> all Normative Statements regarding the TTP component). >>> >>> >>> >>> [2] Conformant implementations are free to ignore Normative >>> Statements 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 >>> Statements 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. >>> >>> >>> In addition to this wording in the STIX 1.2.1 language-level >>> multipart specification there will also be separate >>> conformance wording within the STIX 1.2.1 XML Binding >>> Specification (with accompanying XSD reference implementation). >>> The conformance wording for the XML binding specification and >>> any other binding specification (e.g. JSON) is likely to be >>> more technical. >>> >>> >>> We do recognize that the proposed clause #1 above lacks >>> explicit specificity on exactly what portions of STIX are >>> in-scope or out-of-scope for a given implementation. For this >>> reason, we continue to strongly suggest the use of STIX >>> Profiles to make such distinctions clear. We considered the >>> option of proposing that they be required here in the >>> conformance section but decided against it for STIX 1.2.1 due >>> to the requirement for minimal change from 1.2 and due to the >>> limitations with the current mechanism for capturing and >>> conveying Profiles. It is believed that such a mandatory >>> requirement will likely be necessary for STIX 2.0 to make >>> widespread conformance assertion and assessment more practical. >>> Because of this the limitations in the current profile >>> mechanism will likely need to be addressed as part of the >>> overall STIX 2.0 effort. >>> >>> What do you all think about spinning up a separate work >>> product effort to look into the Profile representation and >>> tooling issues? >>> >>> >>> So, the net-net here is that we are looking for your >>> concurrence or concerns on the above proposed wording. We need >>> to include the wording in the specification drafts that are >>> targeted for EOB Friday delivery so hearing from you within the >>> next day or two is important. Don’t be too concerned if you >>> cannot provide feedback that quickly. This wording is not yet >>> case in stone. If we discover issues with it we can still tweak >>> it as necessary as we review the drafts next week. >>> >>> >>> Thank you for your consideration and thoughts on this matter. >>> >>> >>> sean >>> >>> >>> >>> >>> >>> >>> -- >>> >>> /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 <tel:%2B1%20973-996-2298> Mobile: +1 >>> 201-341-1393 <tel:%2B1%20201-341-1393> >> >> -- Patrick Durusau patrick@durusau.net >> < mailto:patrick@durusau.net > 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 >> > > -- Patrick Durusau patrick@durusau.net < mailto:patrick@durusau.net > > 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 > > > > > -- > > /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 patrick@durusau.net 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWmRJoAAoJEFPGsgi3MgycYTEQAKjnlTqEKHJJ0HdXmFCxBanM xiUl936n0QgKhch88G9oA7OaRyJaDbqEOgdo2CCyxdWZqMWDhfmr5BAiaB4NHyaB JzbCS2Oao77UkhPFZlvJw9xWPv9Zlod66rolzXdeG/YSKnWUCnr7hosP7gpoWpRd l8OiI+Yc/PlriLPI56dIujec4JO6LXAyOyrUPYY30sw8a+oK/u4A2vw05IdtRSMN f/UOc97+/mNc48HVi71qclrR9jdc8uImRTWChsrR6rerw6yv5W3Cqjuvyd5WU61J vHbmUPEmKzZ8Ci8oijQWHBBQydkldBsm44XHMQ6tax22RG5C7qCP6r28HmlzhMZV DHWcQVDtIkz+33NG7UdBW4wDL2sfUTvoFwBbujq7EcT13cmzr/Rw1qsdfBthiLQc +vXFr2nIfcTl8k3LXH+4iV0WqZsxmKFCt8PSlOmh6VlqmlVF7bnOu6D5Uwditrbg 8yjRYpVVgIOExw/3aGrOycq35/VEa/nO1NQRcvpo9sW05rHmxLZHy2epVk/NyMgj GZY2twAal7tiwwhcqIujdpBAMUggaqOGGTMqOvz5zvDLG90K+VZSgPC2iedOXvYK tbV+fZuAXYgN+oSwOMcZt0NRXDwCJ2YX0J82R599psDrG83QoSSQaj3pfl6cFPCu cuLDmm3XfTI2+RQIa8Rr =w47a -----END PGP SIGNATURE-----

Hmmm. I'm coming back to this as the STIX and TAXII specs are about to go out the door for review. They would not be interested in such an approach because they do want to standardize these first specs but it is an interesting idea. Do we have any other examples of where this has happened do you think?  I would be happy to launch a conversation on the topic with the process committee if we see the need.  That said, I would like the TAB to provide comments on the conformance clauses for their formal review. They have provided conformance clauses and it may be that the issue here is "detailed... criteria tied to specific structures" - in other words, Sean (I think that was him) may have thought this was a much bigger undertaking that it would really need to be. Plus, they may be having debates about what specific structures even mean within the spec. In either case, I think the TAB insights can definitely put the pressure on them to improve the clauses before the final results.  And of course, if you think that the clauses are so weak as to provide no effective criteria at all, then I have grounds on which to go back and have a frank conversation.  They have proved receptive to such feedback by the way. I'm sure we can reach some conclusion.  /chet On Tue, Sep 1, 2015 at 12:09 PM, Patrick Durusau < patrick@durusau.net > wrote: Chet, I find even the entertaining of such suggestions from the Cyber Threat Intel STIX TC disturbing. By their own admission: ***** Because of these factors, complex and detailed conformance criteria tied to specific structures of the languages or protocols are not really practical. ***** They have no intent whatsoever in following the TC process for conformance clauses. That's unfortunate because the OASIS Board and OASIS members have labored for years to produce a practical yet formal approach to standards making that meets the need to proceed without undue delay but also in a manner that produces interoperable implementations based on quality work. Rather than set an unfortunate precedent for others to attempt to follow, why not: 1. Have the TC formally adopt the existing versions in toto as TC work products and inputs into their work at OASIS. 2. As a result of formal adoption by the TC as TC work products, the TC Admin affixes an OASIS cover page, much like ISO does with a PAS submission, on the adopted work. 3. Probably need a designation: TC Adopted Work Product or some such to distinguish it from notes and specifications. But it can't advance without full conformance to the OASIS TC process. This seems to be a recurrent problem although I am hard pressed to say why changing work is such a surprise when people arrive at OASIS. A question that others need to explore. With the board meeting coming up in October, such a process, which would not involve public review cycles, etc. would both meet the immediate needs of the Cyber Threat Intel STIX TC and not penalize other OASIS members for having been so foolish as to follow the TC process in preparation of their work. The foregoing may sound harsh but kudos to the TC for admitting that they are not going to follow the TC process and its conformance clause requirements. Such honesty isn't common. Hope you are having a great day! Patrick PS: I am willing to draft a first cut at the TC Adopted Work Product addition to the TC Process if that would help. On 09/01/2015 09:56 AM, Chet Ensign wrote: Just FYI on the approach that the Cyber Threat Intel STIX subcommittee is proposing for conformance clauses for their current draft. I'm happy to explain more on their thinking if you are interested. They are likely to revisit this when they start work on 2.0.  ---------- Forwarded message ---------- From: Barnum, Sean D. < sbarnum@mitre.org > Date: Mon, Aug 31, 2015 at 2:33 PM Subject: [cti-stix] Conformance clauses for the STIX specification documents To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > STIX SC community, As we work to move over the existing STIX 1.2 language specification content into the STIX 1.2.1 language specification documents that are compliant with the OASIS document templates one of the challenges we face is deciding how best to handle the Conformance clause sections of the specification documents. By OASIS definition a conformance clause is: " A statement in the Conformance section of a specification that provides a high-level description of what is required for an artifact to conform. It, in turn, refers to other parts of the specification for details. A Conformance Clause must reference one or more Normative Statements, directly or indirectly, and may refer to another Conformance Clause." Such conformance clauses are not something we have had to explicitly deal with to date so it is something new for our community. On top of the novelty of conformance clauses in general we also need to consider the comprehensiveness and flexibility of STIX/CybOX, the diversity of potential use cases and the fact that these first releases in OASIS must be as minimal change as possible from the pre-OASIS versions. Because of these factors, complex and detailed conformance criteria tied to specific structures of the languages or protocols are not really practical. We need to find a way to achieve the intent of the conformance sections but do so in a more general and practical way. After reviewing the OASIS guidelines and examples on conformance clauses and taking a look at what Mark & Bret came up with for TAXII, we are proposing something very closely aligned to the TAXII approach with a few necessary tweaks for STIX. For the STIX 1.2.1 language specifications, we propose the following wording for the Conformance section: Conformance 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 Statements that apply to the portions of STIX they implement (e.g., Implementers of the entire TTP component must conform to all Normative Statements regarding the TTP component).   [2] Conformant implementations are free to ignore Normative Statements 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 Statements 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. In addition to this wording in the STIX 1.2.1 language-level multipart specification there will also be separate conformance wording within the STIX 1.2.1 XML Binding Specification (with accompanying XSD reference implementation). The conformance wording for the XML binding specification and any other binding specification (e.g. JSON) is likely to be more technical. We do recognize that the proposed clause #1 above lacks explicit specificity on exactly what portions of STIX are in-scope or out-of-scope for a given implementation. For this reason, we continue to strongly suggest the use of STIX Profiles to make such distinctions clear. We considered the option of proposing that they be required here in the conformance section but decided against it for STIX 1.2.1 due to the requirement for minimal change from 1.2 and due to the limitations with the current mechanism for capturing and conveying Profiles. It is believed that such a mandatory requirement will likely be necessary for STIX 2.0 to make widespread conformance assertion and assessment more practical. Because of this the limitations in the current profile mechanism will likely need to be addressed as part of the overall STIX 2.0 effort. What do you all think about spinning up a separate work product effort to look into the Profile representation and tooling issues? So, the net-net here is that we are looking for your concurrence or concerns on the above proposed wording. We need to include the wording in the specification drafts that are targeted for EOB Friday delivery so hearing from you within the next day or two is important. Don’t be too concerned if you cannot provide feedback that quickly. This wording is not yet case in stone. If we discover issues with it we can still tweak it as necessary as we review the drafts next week. Thank you for your consideration and thoughts on this matter. sean   -- /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 patrick@durusau.net 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 -- /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