OASIS Cyber Threat Intelligence (CTI) TC

 View Only
Back to discussions
Expand all | Collapse all

Re: [cti] Status of CTI OASIS Open Repositories

  • 1.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 09-28-2016 18:09
    Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-) Regards, Ivan On 9/28/16, 12:04 PM, "cti@lists.oasis-open.org on behalf of Back, Greg" <cti@lists.oasis-open.org on behalf of gback@mitre.org> wrote: >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS. > >- cti-stix2-json-schemas >- cti-pattern-validator >- cti-marking-prototype >- cti-stix-visualization >- cti-stix-validator > >There are two other repositories that exist, but do not (yet) have any content: > >- cti-documentation >- cti-cybox3-json-schemas > >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor License Agreement (CLA): https://www.oasis-open.org/resources/open-repositories/cla . This applies *even to TC members*. > >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions about the process, etc. > >You can find the repositories here: https://github.com/oasis-open > >Thanks, > >Greg Back >MITRE > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >


  • 2.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 09-29-2016 00:49
    Hello all; IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement. It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like stix-tools to cover this and also future potential contributions that would not fit into these buckets? -- Sent from my mobile device, please excuse any typos. Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories --- From: "Kirillov, Ivan A." <ikirillov@mitre.org> To: "Back, Greg" <gback@mitre.org>, cti@lists.oasis-open.org Date: Wed, Sep 28, 2016 2:09 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-) Regards, Ivan On 9/28/16, 12:04 PM, cti@lists.oasis-open.org on behalf of Back, Greg <cti@lists.oasis-open.org on behalf of gback@mitre.org > wrote: >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS. > >- cti-stix2-json-schemas >- cti-pattern-validator >- cti-marking-prototype >- cti-stix-visualization >- cti-stix-validator > >There are two other repositories that exist, but do not (yet) have any content: > >- cti-documentation >- cti-cybox3-json-schemas > >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor License Agreement (CLA): https://www.oasis-open.org/resources/open-repositories/cla . This applies *even to TC members*. > >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions about the process, etc. > >You can find the repositories here: https://github.com/oasis-open > >Thanks, > >Greg Back >MITRE > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail.  Follow this link to all your TCs in OASIS at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >


  • 3.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 09-29-2016 01:35
    Jason, The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race. Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository. One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent)  design that uses folders within a single repository.   Using separate repos means less work (design work, workday-work) when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo.  Just use one taxonomy of types/labels without namespace worries.  And: you can five write privs to relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects... But as always: it's up to the TC, and I am no expert here. - Robin On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Hello all; IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement. It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets? -- Sent from my mobile device, please excuse any typos. Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories --- From: "Kirillov, Ivan A." < ikirillov@mitre.org > To: "Back, Greg" < gback@mitre.org >, cti@lists.oasis-open.org Date: Wed, Sep 28, 2016 2:09 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-) Regards, Ivan On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org on behalf of Back, Greg" < cti@lists.oasis-open.org on behalf of gback@mitre.org > wrote: >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS. > >- cti-stix2-json-schemas >- cti-pattern-validator >- cti-marking-prototype >- cti-stix-visualization >- cti-stix-validator > >There are two other repositories that exist, but do not (yet) have any content: > >- cti-documentation >- cti-cybox3-json-schemas > >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor License Agreement (CLA): https://www.oasis-open.org/ resources/open-repositories/ cla . This applies *even to TC members*. > >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions about the process, etc. > >You can find the repositories here: https://github.com/oasis-open > >Thanks, > >Greg Back >MITRE > >----------------------------- ------------------------------ ---------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/ apps/org/workgroup/portal/my_ workgroups.php > -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783


  • 4.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 09-29-2016 12:03
    I hear what you are saying and there are definitely pros and cons to having some more generic repositories - but I am trying to envision the near future where we will hopefully have a whole bunch of various code contributions from vendors, members and hopefully non-members alike. This is just my opinion of course, but I think we should try to make the process to contribute code to the TC as light-weight as possible, to encourage people to contribute to our open repositories vs. just throw it up on their own Github account - as if they do that, then IPR and access is not as assured. Having to make a motion to create a new repository every time someone wants to contribute some new code, is a fairly heavyweight process in my opinion. It also means that only TC members can contribute any "new things", because the public can't trigger a vote on making a new repository - so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member). - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/28/2016 10:35:01 PM---Jason, The decision about creating something like "stix-tools" is (of course) a From: Robin Cover <robin@oasis-open.org> To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." <ikirillov@mitre.org>, "Back, Greg" <gback@mitre.org>, OASIS CTI TC Discussion List <cti@lists.oasis-open.org>, Robin Cover <robin@oasis-open.org> Date: 09/28/2016 10:35 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: <cti@lists.oasis-open.org> Jason, The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race. Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository. One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent)  design that uses folders within a single repository.   Using separate repos means less work (design work, workday-work) when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo.  Just use one taxonomy of types/labels without namespace worries.  And: you can five write privs to relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects... But as always: it's up to the TC, and I am no expert here. - Robin On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Hello all; IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement. It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets? -- Sent from my mobile device, please excuse any typos. Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories --- From: "Kirillov, Ivan A." < ikirillov@mitre.org > To: "Back, Greg" < gback@mitre.org >, cti@lists.oasis-open.org Date: Wed, Sep 28, 2016 2:09 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-) Regards, Ivan On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org  on behalf of Back, Greg" < cti@lists.oasis-open.org  on behalf of gback@mitre.org > wrote: >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS. > >- cti-stix2-json-schemas >- cti-pattern-validator >- cti-marking-prototype >- cti-stix-visualization >- cti-stix-validator > >There are two other repositories that exist, but do not (yet) have any content: > >- cti-documentation >- cti-cybox3-json-schemas > >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor License Agreement (CLA): https://www.oasis-open.org/resources/open-repositories/cla  . This applies *even to TC members*. > >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions about the process, etc. > >You can find the repositories here: https://github.com/oasis-open   > >Thanks, > >Greg Back >MITRE > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   > -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783


  • 5.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 09-29-2016 12:27
    On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I hear what you are saying and there are definitely pros and cons to having some more generic repositories - but I am trying to envision the near future where we will hopefully have a whole bunch of various code contributions from vendors, members and hopefully non-members alike. This is just my opinion of course, but I think we should try to make the process to contribute code to the TC as light-weight as possible, to encourage people to contribute to our open repositories vs. just throw it up on their own Github account - as if they do that, then IPR and access is not as assured. Having to make a motion to create a new repository every time someone wants to contribute some new code, is a fairly heavyweight process in my opinion. It also means that only TC members can contribute any "new things", because the public can't trigger a vote on making a new repository - so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member). Jason, I'll raise the matter of requiring a motion/ballot with Staff.  We probably want some kind of confirmation from the TC Chairs(s) -- indicating that there was consensus on the key elements of the request (name, Maintainers, choice of FOSS license, etc) Re: > a whole bunch of various code contributions from vendors, members and hopefully non-members alike That sounds great, and OASIS Open Repositories are intended to support that.   It's a TC decision whether you want more or fewer repositories. It's a TC decision as to whether the repos are described as "generic" or having closely defined focus. I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" For the OASIS Open Repositories, once the repo is created, anyone from "the public" (non-TC member) can be a full participant, including Maintainer, per consensus.  They can contribute "new things" in the same way as anyone can contribute new things to any GitHub public repository.  Perhaps I misunderstand your concern.... I have assumed, maybe incorrectly, that your mention of a new repository (additional to those reported by Greg Back [1]) meant you want a new OASIS Open Repository (  https://www.oasis-open.org/resources/open-repositories ) - Robin [1] cti-stix2-json-schemas cti-pattern-validator cti-marking-prototype cti-stix-visualization cti-stix-validator cti-documentation cti-cybox3-json-schemas   - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/28/2016 10:35:01 PM---Jason, The decision about creating something like "stix-tools" is (of course) a From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/28/2016 10:35 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > Jason, The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race. Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository. One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent)  design that uses folders within a single repository.   Using separate repos means less work (design work, workday-work) when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo.  Just use one taxonomy of types/labels without namespace worries.  And: you can five write privs to relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects... But as always: it's up to the TC, and I am no expert here. - Robin On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Hello all; IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement. It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets? -- Sent from my mobile device, please excuse any typos. Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories --- From: "Kirillov, Ivan A." < ikirillov@mitre.org > To: "Back, Greg" < gback@mitre.org >, cti@lists.oasis-open.org Date: Wed, Sep 28, 2016 2:09 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-) Regards, Ivan On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org  on behalf of Back, Greg" < cti@lists.oasis-open.org  on behalf of gback@mitre.org > wrote: >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS. > >- cti-stix2-json-schemas >- cti-pattern-validator >- cti-marking-prototype >- cti-stix-visualization >- cti-stix-validator > >There are two other repositories that exist, but do not (yet) have any content: > >- cti-documentation >- cti-cybox3-json-schemas > >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor License Agreement (CLA): https://www.oasis-open.org/ resources/open-repositories/ cla  . This applies *even to TC members*. > >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions about the process, etc. > >You can find the repositories here: https://github.com/oasis-open   > >Thanks, > >Greg Back >MITRE > >----------------------------- ------------------------------ ---------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/ apps/org/workgroup/portal/my_ workgroups.php   > -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/ people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/ newsletterArchive.html Tel: +1 972-296-1783 -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783


  • 6.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 09-29-2016 14:15
    RE " I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" " It is basically tied back to the need, currently, to be a TC member and make a motion if you want to make a new repository, combined with these repositories being tied to very specific projects and not having a generic top-level repository. Imagine a non-TC member has some brand new code they want to contribute, but it does not fall into any of these existing open repository categories, and we have no "generic" type of repository. They can not make a new repository, or even motion to make one, as they are not a TC member. They're stuck. The only way they could donate this code, would be to try to proxy through another TC member to get the repository created for them to commit it to. I strongly suspect that instead of that hassle they would just put it up on their own Github. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/29/2016 09:28:30 AM---On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead <Jason.Keirstead@ca.ibm.com > wrote: From: Robin Cover <robin@oasis-open.org> To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." <ikirillov@mitre.org>, "Back, Greg" <gback@mitre.org>, OASIS CTI TC Discussion List <cti@lists.oasis-open.org>, Robin Cover <robin@oasis-open.org> Date: 09/29/2016 09:28 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: <cti@lists.oasis-open.org> On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I hear what you are saying and there are definitely pros and cons to having some more generic repositories - but I am trying to envision the near future where we will hopefully have a whole bunch of various code contributions from vendors, members and hopefully non-members alike. This is just my opinion of course, but I think we should try to make the process to contribute code to the TC as light-weight as possible, to encourage people to contribute to our open repositories vs. just throw it up on their own Github account - as if they do that, then IPR and access is not as assured. Having to make a motion to create a new repository every time someone wants to contribute some new code, is a fairly heavyweight process in my opinion. It also means that only TC members can contribute any "new things", because the public can't trigger a vote on making a new repository - so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member). Jason, I'll raise the matter of requiring a motion/ballot with Staff.  We probably want some kind of confirmation from the TC Chairs(s) -- indicating that there was consensus on the key elements of the request (name, Maintainers, choice of FOSS license, etc) Re: > a whole bunch of various code contributions from vendors, members and hopefully non-members alike That sounds great, and OASIS Open Repositories are intended to support that.   It's a TC decision whether you want more or fewer repositories. It's a TC decision as to whether the repos are described as "generic" or having closely defined focus. I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" For the OASIS Open Repositories, once the repo is created, anyone from "the public" (non-TC member) can be a full participant, including Maintainer, per consensus.  They can contribute "new things" in the same way as anyone can contribute new things to any GitHub public repository.  Perhaps I misunderstand your concern.... I have assumed, maybe incorrectly, that your mention of a new repository (additional to those reported by Greg Back [1]) meant you want a new OASIS Open Repository (  https://www.oasis-open.org/resources/open-repositories ) - Robin [1] cti-stix2-json-schemas cti-pattern-validator cti-marking-prototype cti-stix-visualization cti-stix-validator cti-documentation cti-cybox3-json-schemas   - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/28/2016 10:35:01 PM---Jason, The decision about creating something like "stix-tools" is (of course) a From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/28/2016 10:35 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > Jason, The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race. Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository. One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent)  design that uses folders within a single repository.   Using separate repos means less work (design work, workday-work) when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo.  Just use one taxonomy of types/labels without namespace worries.  And: you can five write privs to relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects... But as always: it's up to the TC, and I am no expert here. - Robin On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Hello all; IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement. It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets? -- Sent from my mobile device, please excuse any typos. Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories --- From: "Kirillov, Ivan A." < ikirillov@mitre.org > To: "Back, Greg" < gback@mitre.org >, cti@lists.oasis-open.org Date: Wed, Sep 28, 2016 2:09 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-) Regards, Ivan On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org  on behalf of Back, Greg" < cti@lists.oasis-open.org  on behalf of gback@mitre.org > wrote: >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS. > >- cti-stix2-json-schemas >- cti-pattern-validator >- cti-marking-prototype >- cti-stix-visualization >- cti-stix-validator > >There are two other repositories that exist, but do not (yet) have any content: > >- cti-documentation >- cti-cybox3-json-schemas > >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor License Agreement (CLA): https://www.oasis-open.org/resources/open-repositories/cla  . This applies *even to TC members*. > >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions about the process, etc. > >You can find the repositories here: https://github.com/oasis-open   > >Thanks, > >Greg Back >MITRE > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   > -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783 -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783


  • 7.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 09-29-2016 14:29
    On Thu, Sep 29, 2016 at 9:14 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: RE " I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" " It is basically tied back to the need, currently, to be a TC member and make a motion if you want to make a new repository OK, I understand.  I'll raise the issue with Staff: can/should we support some means whereby a non-TC Member can easily make request for a new OASIS Open Repository where it's perceived that no existing Open Repository repository is suitable. , combined with these repositories being tied to very specific projects and not having a generic top-level repository. In the case at hand: the CTI TC can create an OASIS Open Repository described as "generic":  that is your choice.   I suppose you could also characterize some new OASIS Open Repository as "top-level" (notionally) if the TC members wanted to do that. Imagine a non-TC member has some brand new code they want to contribute, but it does not fall into any of these existing open repository categories, and we have no "generic" type of repository. They can not make a new repository, or even motion to make one, as they are not a TC member. They're stuck. The only way they could donate this code, would be to try to proxy through another TC member to get the repository created for them to commit it to. I strongly suspect that instead of that hassle they would just put it up on their own Github. Thanks for the clarification via examples.  I'll certainly raise the issue with Staff.  All such suggestions for improvement are welcome. Kindest regards and best wishes, - Robin   - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/29/2016 09:28:30 AM---On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/29/2016 09:28 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I hear what you are saying and there are definitely pros and cons to having some more generic repositories - but I am trying to envision the near future where we will hopefully have a whole bunch of various code contributions from vendors, members and hopefully non-members alike. This is just my opinion of course, but I think we should try to make the process to contribute code to the TC as light-weight as possible, to encourage people to contribute to our open repositories vs. just throw it up on their own Github account - as if they do that, then IPR and access is not as assured. Having to make a motion to create a new repository every time someone wants to contribute some new code, is a fairly heavyweight process in my opinion. It also means that only TC members can contribute any "new things", because the public can't trigger a vote on making a new repository - so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member). Jason, I'll raise the matter of requiring a motion/ballot with Staff.  We probably want some kind of confirmation from the TC Chairs(s) -- indicating that there was consensus on the key elements of the request (name, Maintainers, choice of FOSS license, etc) Re: > a whole bunch of various code contributions from vendors, members and hopefully non-members alike That sounds great, and OASIS Open Repositories are intended to support that.   It's a TC decision whether you want more or fewer repositories. It's a TC decision as to whether the repos are described as "generic" or having closely defined focus. I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" For the OASIS Open Repositories, once the repo is created, anyone from "the public" (non-TC member) can be a full participant, including Maintainer, per consensus.  They can contribute "new things" in the same way as anyone can contribute new things to any GitHub public repository.  Perhaps I misunderstand your concern.... I have assumed, maybe incorrectly, that your mention of a new repository (additional to those reported by Greg Back [1]) meant you want a new OASIS Open Repository (  https://www.oasis-open.org/ resources/open-repositories ) - Robin [1] cti-stix2-json-schemas cti-pattern-validator cti-marking-prototype cti-stix-visualization cti-stix-validator cti-documentation cti-cybox3-json-schemas   - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/28/2016 10:35:01 PM---Jason, The decision about creating something like "stix-tools" is (of course) a From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/28/2016 10:35 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > Jason, The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race. Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository. One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent)  design that uses folders within a single repository.   Using separate repos means less work (design work, workday-work) when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo.  Just use one taxonomy of types/labels without namespace worries.  And: you can five write privs to relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects... But as always: it's up to the TC, and I am no expert here. - Robin On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Hello all; IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement. It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets? -- Sent from my mobile device, please excuse any typos. Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories --- From: "Kirillov, Ivan A." < ikirillov@mitre.org > To: "Back, Greg" < gback@mitre.org >, cti@lists.oasis-open.org Date: Wed, Sep 28, 2016 2:09 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-) Regards, Ivan On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org  on behalf of Back, Greg" < cti@lists.oasis-open.org  on behalf of gback@mitre.org > wrote: >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS. > >- cti-stix2-json-schemas >- cti-pattern-validator >- cti-marking-prototype >- cti-stix-visualization >- cti-stix-validator > >There are two other repositories that exist, but do not (yet) have any content: > >- cti-documentation >- cti-cybox3-json-schemas > >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor License Agreement (CLA): https://www.oasis-open.org/ resources/open-repositories/ cla  . This applies *even to TC members*. > >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions about the process, etc. > >You can find the repositories here: https://github.com/oasis-open   > >Thanks, > >Greg Back >MITRE > >----------------------------- ------------------------------ ---------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/ apps/org/workgroup/portal/my_ workgroups.php   > -- -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783


  • 8.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-03-2016 20:09
    The problem with all of this is that it is not a collection of repos, but rather specific repos.  Including multiple projects in a single repo is considered "bad form".  Yes, you can do funky things with TAGS and you can even use different directories in the same repo.  But that kind of break the git model.  So instead of OASIS creating a oasis-open project with a bunch of arrant TC repos underneath, it seems like OASIS should setup a TC specific "projects".  Then the TC can create as many repos on the project that it wants. Bret From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Robin Cover <robin@oasis-open.org> Sent: Thursday, September 29, 2016 8:28:43 AM To: Jason Keirstead Cc: Kirillov, Ivan A.; Back, Greg; OASIS CTI TC Discussion List; Robin Cover Subject: Re: [cti] Status of CTI OASIS Open Repositories   On Thu, Sep 29, 2016 at 9:14 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: RE " I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" " It is basically tied back to the need, currently, to be a TC member and make a motion if you want to make a new repository OK, I understand.  I'll raise the issue with Staff: can/should we support some means whereby a non-TC Member can easily make request for a new OASIS Open Repository where it's perceived that no existing Open Repository repository is suitable. , combined with these repositories being tied to very specific projects and not having a generic top-level repository. In the case at hand: the CTI TC can create an OASIS Open Repository described as "generic":  that is your choice.   I suppose you could also characterize some new OASIS Open Repository as "top-level" (notionally) if the TC members wanted to do that. Imagine a non-TC member has some brand new code they want to contribute, but it does not fall into any of these existing open repository categories, and we have no "generic" type of repository. They can not make a new repository, or even motion to make one, as they are not a TC member. They're stuck. The only way they could donate this code, would be to try to proxy through another TC member to get the repository created for them to commit it to. I strongly suspect that instead of that hassle they would just put it up on their own Github. Thanks for the clarification via examples.  I'll certainly raise the issue with Staff.  All such suggestions for improvement are welcome. Kindest regards and best wishes, - Robin   - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/29/2016 09:28:30 AM---On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/29/2016 09:28 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I hear what you are saying and there are definitely pros and cons to having some more generic repositories - but I am trying to envision the near future where we will hopefully have a whole bunch of various code contributions from vendors, members and hopefully non-members alike. This is just my opinion of course, but I think we should try to make the process to contribute code to the TC as light-weight as possible, to encourage people to contribute to our open repositories vs. just throw it up on their own Github account - as if they do that, then IPR and access is not as assured. Having to make a motion to create a new repository every time someone wants to contribute some new code, is a fairly heavyweight process in my opinion. It also means that only TC members can contribute any "new things", because the public can't trigger a vote on making a new repository - so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member). Jason, I'll raise the matter of requiring a motion/ballot with Staff.  We probably want some kind of confirmation from the TC Chairs(s) -- indicating that there was consensus on the key elements of the request (name, Maintainers, choice of FOSS license, etc) Re: > a whole bunch of various code contributions from vendors, members and hopefully non-members alike That sounds great, and OASIS Open Repositories are intended to support that.   It's a TC decision whether you want more or fewer repositories. It's a TC decision as to whether the repos are described as "generic" or having closely defined focus. I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" For the OASIS Open Repositories, once the repo is created, anyone from "the public" (non-TC member) can be a full participant, including Maintainer, per consensus.  They can contribute "new things" in the same way as anyone can contribute new things to any GitHub public repository.  Perhaps I misunderstand your concern.... I have assumed, maybe incorrectly, that your mention of a new repository (additional to those reported by Greg Back [1]) meant you want a new OASIS Open Repository (  https://www.oasis-open.org/ resources/open-repositories ) - Robin [1] cti-stix2-json-schemas cti-pattern-validator cti-marking-prototype cti-stix-visualization cti-stix-validator cti-documentation cti-cybox3-json-schemas   - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/28/2016 10:35:01 PM---Jason, The decision about creating something like "stix-tools" is (of course) a From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/28/2016 10:35 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > Jason, The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race. Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository. One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent)  design that uses folders within a single repository.   Using separate repos means less work (design work, workday-work) when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo.  Just use one taxonomy of types/labels without namespace worries.  And: you can five write privs to relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects... But as always: it's up to the TC, and I am no expert here. - Robin On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Hello all; IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement. It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets? -- Sent from my mobile device, please excuse any typos. Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories --- From: "Kirillov, Ivan A." < ikirillov@mitre.org > To: "Back, Greg" < gback@mitre.org >, cti@lists.oasis-open.org Date: Wed, Sep 28, 2016 2:09 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-) Regards, Ivan On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org  on behalf of Back, Greg" < cti@lists.oasis-open.org  on behalf of gback@mitre.org > wrote: >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS. > >- cti-stix2-json-schemas >- cti-pattern-validator >- cti-marking-prototype >- cti-stix-visualization >- cti-stix-validator > >There are two other repositories that exist, but do not (yet) have any content: > >- cti-documentation >- cti-cybox3-json-schemas > >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor License Agreement (CLA): https://www.oasis-open.org/ resources/open-repositories/ cla  . This applies *even to TC members*. > >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions about the process, etc. > >You can find the repositories here: https://github.com/oasis-open   > >Thanks, > >Greg Back >MITRE > >----------------------------- ------------------------------ ---------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/ apps/org/workgroup/portal/my_ workgroups.php   > -- -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783


  • 9.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-04-2016 19:19
    Couldn't we do a git repo containing submodules? Then each tool can have its own git repo, and it can be linked a submodules into the overall tools collection repo. This then makes it easy for everyone to get a copy of all three rows from one place, and yet we avoid the problems with many different people who only need access to parts of the git tree... Cheers Terry MacDonald Cosive On 4 Oct. 2016 9:09 am, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote: The problem with all of this is that it is not a collection of repos, but rather specific repos.  Including multiple projects in a single repo is considered "bad form".  Yes, you can do funky things with TAGS and you can even use different directories in the same repo.  But that kind of break the git model.  So instead of OASIS creating a oasis-open project with a bunch of arrant TC repos underneath, it seems like OASIS should setup a TC specific "projects".  Then the TC can create as many repos on the project that it wants. Bret From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org > Sent: Thursday, September 29, 2016 8:28:43 AM To: Jason Keirstead Cc: Kirillov, Ivan A.; Back, Greg; OASIS CTI TC Discussion List; Robin Cover Subject: Re: [cti] Status of CTI OASIS Open Repositories   On Thu, Sep 29, 2016 at 9:14 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: RE " I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" " It is basically tied back to the need, currently, to be a TC member and make a motion if you want to make a new repository OK, I understand.  I'll raise the issue with Staff: can/should we support some means whereby a non-TC Member can easily make request for a new OASIS Open Repository where it's perceived that no existing Open Repository repository is suitable. , combined with these repositories being tied to very specific projects and not having a generic top-level repository. In the case at hand: the CTI TC can create an OASIS Open Repository described as "generic":  that is your choice.   I suppose you could also characterize some new OASIS Open Repository as "top-level" (notionally) if the TC members wanted to do that. Imagine a non-TC member has some brand new code they want to contribute, but it does not fall into any of these existing open repository categories, and we have no "generic" type of repository. They can not make a new repository, or even motion to make one, as they are not a TC member. They're stuck. The only way they could donate this code, would be to try to proxy through another TC member to get the repository created for them to commit it to. I strongly suspect that instead of that hassle they would just put it up on their own Github. Thanks for the clarification via examples.  I'll certainly raise the issue with Staff.  All such suggestions for improvement are welcome. Kindest regards and best wishes, - Robin   - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/29/2016 09:28:30 AM---On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/29/2016 09:28 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I hear what you are saying and there are definitely pros and cons to having some more generic repositories - but I am trying to envision the near future where we will hopefully have a whole bunch of various code contributions from vendors, members and hopefully non-members alike. This is just my opinion of course, but I think we should try to make the process to contribute code to the TC as light-weight as possible, to encourage people to contribute to our open repositories vs. just throw it up on their own Github account - as if they do that, then IPR and access is not as assured. Having to make a motion to create a new repository every time someone wants to contribute some new code, is a fairly heavyweight process in my opinion. It also means that only TC members can contribute any "new things", because the public can't trigger a vote on making a new repository - so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member). Jason, I'll raise the matter of requiring a motion/ballot with Staff.  We probably want some kind of confirmation from the TC Chairs(s) -- indicating that there was consensus on the key elements of the request (name, Maintainers, choice of FOSS license, etc) Re: > a whole bunch of various code contributions from vendors, members and hopefully non-members alike That sounds great, and OASIS Open Repositories are intended to support that.   It's a TC decision whether you want more or fewer repositories. It's a TC decision as to whether the repos are described as "generic" or having closely defined focus. I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" For the OASIS Open Repositories, once the repo is created, anyone from "the public" (non-TC member) can be a full participant, including Maintainer, per consensus.  They can contribute "new things" in the same way as anyone can contribute new things to any GitHub public repository.  Perhaps I misunderstand your concern.... I have assumed, maybe incorrectly, that your mention of a new repository (additional to those reported by Greg Back [1]) meant you want a new OASIS Open Repository (  https://www.oasis-open.org/r esources/open-repositories ) - Robin [1] cti-stix2-json-schemas cti-pattern-validator cti-marking-prototype cti-stix-visualization cti-stix-validator cti-documentation cti-cybox3-json-schemas   - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/28/2016 10:35:01 PM---Jason, The decision about creating something like "stix-tools" is (of course) a From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/28/2016 10:35 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > Jason, The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race. Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository. One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent)  design that uses folders within a single repository.   Using separate repos means less work (design work, workday-work) when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo.  Just use one taxonomy of types/labels without namespace worries.  And: you can five write privs to relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects... But as always: it's up to the TC, and I am no expert here. - Robin On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Hello all; IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement. It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets? -- Sent from my mobile device, please excuse any typos. Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories --- From: "Kirillov, Ivan A." < ikirillov@mitre.org > To: "Back, Greg" < gback@mitre.org >, cti@lists.oasis-open.org Date: Wed, Sep 28, 2016 2:09 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-) Regards, Ivan On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org  on behalf of Back, Greg" < cti@lists.oasis-open.org  on behalf of gback@mitre.org > wrote: >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS. > >- cti-stix2-json-schemas >- cti-pattern-validator >- cti-marking-prototype >- cti-stix-visualization >- cti-stix-validator > >There are two other repositories that exist, but do not (yet) have any content: > >- cti-documentation >- cti-cybox3-json-schemas > >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor License Agreement (CLA): https://www.oasis-open.org/res ources/open-repositories/cla  . This applies *even to TC members*. > >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions about the process, etc. > >You can find the repositories here: https://github.com/oasis-open   > >Thanks, > >Greg Back >MITRE > >----------------------------- ------------------------------ ---------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/ap ps/org/workgroup/portal/my_wor kgroups.php   > -- -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/ people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/ newsletterArchive.html Tel: +1 972-296-1783


  • 10.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-04-2016 20:56




    For the other git neophytes out there:
    https://git-scm.com/book/en/v2/Git-Tools-Submodules
    http://blogs.atlassian.com/2013/03/git-submodules-workflows-tips/
     
    This seems like a viable approach.

     


    From:
    <cti@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@cosive.com>
    Date: Tuesday, October 4, 2016 at 3:19 PM
    To: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>
    Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Robin Cover <robin@oasis-open.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "Kirillov, Ivan A." <ikirillov@mitre.org>, "Back, Greg" <gback@mitre.org>
    Subject: Re: [cti] Status of CTI OASIS Open Repositories


     

    Couldn't we do a git repo containing submodules? Then each tool can have its own git repo, and it can be linked a submodules into the overall tools collection repo.

    This then makes it easy for everyone to get a copy of all three rows from one place, and yet we avoid the problems with many different people who only need access to parts of the git tree...
    Cheers
    Terry MacDonald
    Cosive

     

    On 4 Oct. 2016 9:09 am, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote:



    The problem with all of this is that it is not a collection of repos, but rather specific repos.  Including multiple projects in a single repo is considered "bad form".  Yes, you can do funky things with TAGS
    and you can even use different directories in the same repo.  But that kind of break the git model.  So instead of OASIS creating a oasis-open project with a bunch of arrant TC repos underneath, it seems like OASIS should setup a TC specific "projects".  Then
    the TC can create as many repos on the project that it wants.
     
    Bret





    From:
    cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org >
    Sent: Thursday, September 29, 2016 8:28:43 AM
    To: Jason Keirstead
    Cc: Kirillov, Ivan A.; Back, Greg; OASIS CTI TC Discussion List; Robin Cover
    Subject: Re: [cti] Status of CTI OASIS Open Repositories

     






    On Thu, Sep 29, 2016 at 9:14 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:


    RE " I don't quite understand your meaning here:


    "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" "

    It is basically tied back to the need, currently, to be a TC member and make a motion if you want to make a new repository



    OK, I understand.  I'll raise the issue with Staff: can/should we support some means whereby a non-TC Member can easily make request for a new OASIS Open Repository where it's perceived that no existing Open Repository repository is suitable.



    , combined with these repositories being tied to very specific projects and not having a generic top-level repository.



    In the case at hand: the CTI TC can create an OASIS Open Repository described as "generic":  that is your choice.   I suppose you could also characterize some new OASIS Open Repository as "top-level" (notionally) if the TC members wanted
    to do that.


     




    Imagine a non-TC member has some brand new code they want to contribute, but it does not fall into any of these existing open repository categories, and we have no "generic" type of repository. They can not make a new repository, or even motion to make one,
    as they are not a TC member. They're stuck. The only way they could donate this code, would be to try to proxy through another TC member to get the repository created for them to commit it to. I strongly suspect that instead of that hassle they would just
    put it up on their own Github.



     


    Thanks for the clarification via examples.  I'll certainly raise the issue with Staff.  All such suggestions for improvement are welcome.


     


    Kindest regards and best wishes,


     


    - Robin


     


     




    -
    Jason Keirstead
    STSM, Product Architect, Security Intelligence, IBM Security Systems
    www.ibm.com/security
    www.securityintelligence.com

    Without data, all you are is just another person with an opinion - Unknown


    Robin Cover ---09/29/2016 09:28:30 AM---On Thu, Sep
    29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:

    From: Robin Cover < robin@oasis-open.org >
    To: Jason Keirstead/CanEast/IBM@IBMCA
    Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >,
    OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org >
    Date: 09/29/2016 09:28 AM
    Subject: Re: [cti] Status of CTI OASIS Open Repositories
    Sent by: < cti@lists.oasis-open.org >






    On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:

    I hear what you are saying and there are definitely pros and cons to having some more generic repositories - but I am trying to envision the near future where we will hopefully have
    a whole bunch of various code contributions from vendors, members and hopefully non-members alike. This is just my opinion of course, but I think we should try to make the process to contribute code to the TC as light-weight as possible, to encourage people
    to contribute to our open repositories vs. just throw it up on their own Github account - as if they do that, then IPR and access is not as assured. Having to make a motion to create a new repository every time someone wants to contribute some new code, is
    a fairly heavyweight process in my opinion. It also means that only TC members can contribute any "new things", because the public can't trigger a vote on making a new repository - so the public is basically only able to contribute to things that already exist,
    not contribute anything new (unless they proxy through a member).

    Jason, I'll raise the matter of requiring a motion/ballot with Staff.  We probably want some kind of confirmation from the TC Chairs(s) -- indicating that there was consensus on the key elements of the request (name, Maintainers,
    choice of FOSS license, etc)

    Re:
    > a whole bunch of various code contributions from vendors, members and hopefully non-members alike

    That sounds great, and OASIS Open Repositories are intended to support that.   It's a TC decision whether you want more or fewer repositories. It's a TC decision as to whether the repos are described as "generic" or having closely
    defined focus.

    I don't quite understand your meaning here:

    "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)"

    For the OASIS Open Repositories, once the repo is created, anyone from "the public" (non-TC member) can be a full participant, including Maintainer, per consensus.  They can contribute "new things" in the same way as anyone can
    contribute new things to any GitHub public repository.  Perhaps I misunderstand your concern....

    I have assumed, maybe incorrectly, that your mention of a new repository (additional to those reported by Greg Back [1]) meant you want a new OASIS Open Repository (  https://www.oasis-open.org/resources/open-repositories
    )

    - Robin


    [1]

    cti-stix2-json-schemas
    cti-pattern-validator
    cti-marking-prototype
    cti-stix-visualization
    cti-stix-validator
    cti-documentation
    cti-cybox3-json-schemas

     

    -
    Jason Keirstead
    STSM, Product Architect, Security Intelligence, IBM Security Systems
    www.ibm.com/security
    www.securityintelligence.com

    Without data, all you are is just another person with an opinion - Unknown


    Robin Cover ---09/28/2016 10:35:01
    PM---Jason, The decision about creating something like "stix-tools" is (of course) a

    From: Robin Cover < robin@oasis-open.org >
    To: Jason Keirstead/CanEast/IBM@IBMCA
    Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >,
    Robin Cover < robin@oasis-open.org >
    Date: 09/28/2016 10:35 PM
    Subject: Re: [cti] Status of CTI OASIS Open Repositories
    Sent by: < cti@lists.oasis-open.org >






    Jason,

    The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race.

    Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository.

    One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent)  design that uses folders within a single repository.   Using separate repos means less work (design work, workday-work)
    when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo.  Just use one taxonomy of types/labels without namespace worries.  And: you can five write privs
    to relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects...

    But as always: it's up to the TC, and I am no expert here.

    - Robin

    On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:

    Hello all;

    IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement.

    It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets?

    --
    Sent from my mobile device, please excuse any typos.

    Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories ---





    From:


    "Kirillov, Ivan A." < ikirillov@mitre.org >




    To:


    "Back, Greg" < gback@mitre.org >,
    cti@lists.oasis-open.org




    Date:


    Wed, Sep 28, 2016 2:09 PM




    Subject:


    Re: [cti] Status of CTI OASIS Open Repositories








    Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-)

    Regards,
    Ivan

    On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org  on behalf of Back, Greg" < cti@lists.oasis-open.org  on
    behalf of gback@mitre.org > wrote:

    >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS.

    >
    >- cti-stix2-json-schemas
    >- cti-pattern-validator
    >- cti-marking-prototype
    >- cti-stix-visualization
    >- cti-stix-validator
    >
    >There are two other repositories that exist, but do not (yet) have any content:
    >
    >- cti-documentation
    >- cti-cybox3-json-schemas
    >
    >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor
    License Agreement (CLA): https://www.oasis-open.org/resources/open-repositories/cla  .
    This applies *even to TC members*.
    >
    >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions
    about the process, etc.
    >
    >You can find the repositories here: https://github.com/oasis-open  
    >
    >Thanks,
    >
    >Greg Back
    >MITRE
    >
    >---------------------------------------------------------------------
    >To unsubscribe from this mail list, you must leave the OASIS TC that
    >generates this mail.  Follow this link to all your TCs in OASIS at:
    > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php  
    >




    --


     







     

    --

    Robin Cover
    OASIS, Director of Information Services
    Editor, Cover Pages and XML Daily Newslink
    Email: robin@oasis-open.org
    Staff bio:
    http://www.oasis-open.org/people/staff/robin-cover
    Cover Pages: http://xml.coverpages.org/
    Newsletter:
    http://xml.coverpages.org/newsletterArchive.html
    Tel: +1 972-296-1783















  • 11.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-04-2016 23:02
    Another resource on submodules "Working with submodules" (February 01, 2016) https://github.com/blog/2104-working-with-submodules -rcc On Tue, Oct 4, 2016 at 3:56 PM, Ted Bedwell (tebedwel) < tebedwel@cisco.com > wrote: For the other git neophytes out there: https://git-scm.com/book/en/ v2/Git-Tools-Submodules http://blogs.atlassian.com/ 2013/03/git-submodules- workflows-tips/   This seems like a viable approach.   From: < cti@lists.oasis-open.org > on behalf of Terry MacDonald < terry.macdonald@cosive.com > Date: Tuesday, October 4, 2016 at 3:19 PM To: "Bret Jordan (CS)" < Bret_Jordan@symantec.com > Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories   Couldn't we do a git repo containing submodules? Then each tool can have its own git repo, and it can be linked a submodules into the overall tools collection repo. This then makes it easy for everyone to get a copy of all three rows from one place, and yet we avoid the problems with many different people who only need access to parts of the git tree... Cheers Terry MacDonald Cosive   On 4 Oct. 2016 9:09 am, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote: The problem with all of this is that it is not a collection of repos, but rather specific repos.  Including multiple projects in a single repo is considered "bad form".  Yes, you can do funky things with TAGS and you can even use different directories in the same repo.  But that kind of break the git model.  So instead of OASIS creating a oasis-open project with a bunch of arrant TC repos underneath, it seems like OASIS should setup a TC specific "projects".  Then the TC can create as many repos on the project that it wants.   Bret From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org > Sent: Thursday, September 29, 2016 8:28:43 AM To: Jason Keirstead Cc: Kirillov, Ivan A.; Back, Greg; OASIS CTI TC Discussion List; Robin Cover Subject: Re: [cti] Status of CTI OASIS Open Repositories   On Thu, Sep 29, 2016 at 9:14 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: RE " I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" " It is basically tied back to the need, currently, to be a TC member and make a motion if you want to make a new repository OK, I understand.  I'll raise the issue with Staff: can/should we support some means whereby a non-TC Member can easily make request for a new OASIS Open Repository where it's perceived that no existing Open Repository repository is suitable. , combined with these repositories being tied to very specific projects and not having a generic top-level repository. In the case at hand: the CTI TC can create an OASIS Open Repository described as "generic":  that is your choice.   I suppose you could also characterize some new OASIS Open Repository as "top-level" (notionally) if the TC members wanted to do that.   Imagine a non-TC member has some brand new code they want to contribute, but it does not fall into any of these existing open repository categories, and we have no "generic" type of repository. They can not make a new repository, or even motion to make one, as they are not a TC member. They're stuck. The only way they could donate this code, would be to try to proxy through another TC member to get the repository created for them to commit it to. I strongly suspect that instead of that hassle they would just put it up on their own Github.   Thanks for the clarification via examples.  I'll certainly raise the issue with Staff.  All such suggestions for improvement are welcome.   Kindest regards and best wishes,   - Robin     - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/29/2016 09:28:30 AM---On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/29/2016 09:28 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I hear what you are saying and there are definitely pros and cons to having some more generic repositories - but I am trying to envision the near future where we will hopefully have a whole bunch of various code contributions from vendors, members and hopefully non-members alike. This is just my opinion of course, but I think we should try to make the process to contribute code to the TC as light-weight as possible, to encourage people to contribute to our open repositories vs. just throw it up on their own Github account - as if they do that, then IPR and access is not as assured. Having to make a motion to create a new repository every time someone wants to contribute some new code, is a fairly heavyweight process in my opinion. It also means that only TC members can contribute any "new things", because the public can't trigger a vote on making a new repository - so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member). Jason, I'll raise the matter of requiring a motion/ballot with Staff.  We probably want some kind of confirmation from the TC Chairs(s) -- indicating that there was consensus on the key elements of the request (name, Maintainers, choice of FOSS license, etc) Re: > a whole bunch of various code contributions from vendors, members and hopefully non-members alike That sounds great, and OASIS Open Repositories are intended to support that.   It's a TC decision whether you want more or fewer repositories. It's a TC decision as to whether the repos are described as "generic" or having closely defined focus. I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" For the OASIS Open Repositories, once the repo is created, anyone from "the public" (non-TC member) can be a full participant, including Maintainer, per consensus.  They can contribute "new things" in the same way as anyone can contribute new things to any GitHub public repository.  Perhaps I misunderstand your concern.... I have assumed, maybe incorrectly, that your mention of a new repository (additional to those reported by Greg Back [1]) meant you want a new OASIS Open Repository (  https://www.oasis-open.org/ resources/open-repositories ) - Robin [1] cti-stix2-json-schemas cti-pattern-validator cti-marking-prototype cti-stix-visualization cti-stix-validator cti-documentation cti-cybox3-json-schemas   - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/28/2016 10:35:01 PM---Jason, The decision about creating something like "stix-tools" is (of course) a From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/28/2016 10:35 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > Jason, The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race. Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository. One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent)  design that uses folders within a single repository.   Using separate repos means less work (design work, workday-work) when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo.  Just use one taxonomy of types/labels without namespace worries.  And: you can five write privs to relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects... But as always: it's up to the TC, and I am no expert here. - Robin On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Hello all; IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement. It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets? -- Sent from my mobile device, please excuse any typos. Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories --- From: "Kirillov, Ivan A." < ikirillov@mitre.org > To: "Back, Greg" < gback@mitre.org >, cti@lists.oasis-open.org Date: Wed, Sep 28, 2016 2:09 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-) Regards, Ivan On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org  on behalf of Back, Greg" < cti@lists.oasis-open.org  on behalf of gback@mitre.org > wrote: >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS. > >- cti-stix2-json-schemas >- cti-pattern-validator >- cti-marking-prototype >- cti-stix-visualization >- cti-stix-validator > >There are two other repositories that exist, but do not (yet) have any content: > >- cti-documentation >- cti-cybox3-json-schemas > >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor License Agreement (CLA): https://www.oasis-open.org/ resources/open-repositories/ cla  . This applies *even to TC members*. > >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions about the process, etc. > >You can find the repositories here: https://github.com/oasis-open   > >Thanks, > >Greg Back >MITRE > >----------------------------- ------------------------------ ---------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/ apps/org/workgroup/portal/my_ workgroups.php   > --     --


  • 12.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-05-2016 12:31




    I realize this might go against the grain for some, but maybe we should talk about the organization of GitHub repos on the next working call. Personally, having one OASIS organization for
    _all_ GitHub repos is going to make tracking the work of any single TC more difficult. In addition, one OASIS organization prevents individual TCs from having *.github.io pages, which the STIX/TAXII group has made good use of in the past. I’d like it if we
    could consider a method that would provide the necessary governance AND make the management of GitHub repos a little less cumbersome.
     
    I don’t know if it’s feasible, but I’d be interested in exploring a structure that has the following properties:
    ·         
    A GitHub organization for the CTI TC (e.g., github.com/oasis-cti-tc/)
    ·         
    All CTI TC repos fall under the OASIS-CTI-TC GitHub Org
    ·         
    A set of operating rules for managing repos that does NOT require a ballot. Possible operating rules:

    o    
    New repos require sponsorship by a co-chair and sign-off by the TC chair

    o    
    Repo maintainer has some authority over who has which rights

    o    
    Any part of the operating rules can be superseded by a ballot on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted)
    ·         
    Other considerations?
     
    Basically, my goal would be to free us up a bit in terms of repo management, while staying true to the intent of participating in OASIS. What do people think?
     
    Thank you.
    -Mark
     

    From:
    <cti@lists.oasis-open.org> on behalf of Robin Cover <robin@oasis-open.org>
    Date: Tuesday, October 4, 2016 at 7:02 PM
    To: "Ted Bedwell (tebedwel)" <tebedwel@cisco.com>
    Cc: Terry MacDonald <terry.macdonald@cosive.com>, "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "Kirillov, Ivan A." <ikirillov@mitre.org>, "Back, Greg"
    <gback@mitre.org>
    Subject: Re: [cti] Status of CTI OASIS Open Repositories


     


    Another resource on submodules

     


    "Working with submodules" (February 01, 2016)


    https://github.com/blog/2104-working-with-submodules


     


    -rcc


     

    On Tue, Oct 4, 2016 at 3:56 PM, Ted Bedwell (tebedwel) < tebedwel@cisco.com > wrote:



    For the other git neophytes out there:
    https://git-scm.com/book/en/v2/Git-Tools-Submodules
    http://blogs.atlassian.com/2013/03/git-submodules-workflows-tips/
     
    This seems like a viable approach.

     


    From:
    < cti@lists.oasis-open.org > on behalf of Terry MacDonald < terry.macdonald@cosive.com >
    Date: Tuesday, October 4, 2016 at 3:19 PM
    To: "Bret Jordan (CS)" < Bret_Jordan@symantec.com >
    Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org >,
    Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >
    Subject: Re: [cti] Status of CTI OASIS Open Repositories


     

    Couldn't we do a git repo containing submodules? Then each tool can have its own git repo, and it can be linked a submodules into the overall tools collection repo.

    This then makes it easy for everyone to get a copy of all three rows from one place, and yet we avoid the problems with many different people who only need access to parts of the git tree...
    Cheers
    Terry MacDonald
    Cosive

     

    On 4 Oct. 2016 9:09 am, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote:



    The problem with all of this is that it is not a collection of repos, but rather specific repos.  Including multiple projects in a single repo is considered "bad form".  Yes, you can do funky things with TAGS
    and you can even use different directories in the same repo.  But that kind of break the git model.  So instead of OASIS creating a oasis-open project with a bunch of arrant TC repos underneath, it seems like OASIS should setup a TC specific "projects".  Then
    the TC can create as many repos on the project that it wants.
     
    Bret





    From:
    cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org >
    Sent: Thursday, September 29, 2016 8:28:43 AM
    To: Jason Keirstead
    Cc: Kirillov, Ivan A.; Back, Greg; OASIS CTI TC Discussion List; Robin Cover
    Subject: Re: [cti] Status of CTI OASIS Open Repositories

     






    On Thu, Sep 29, 2016 at 9:14 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:


    RE " I don't quite understand your meaning here:


    "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" "

    It is basically tied back to the need, currently, to be a TC member and make a motion if you want to make a new repository



    OK, I understand.  I'll raise the issue with Staff: can/should we support some means whereby a non-TC Member can easily make request for a new OASIS Open Repository where it's perceived
    that no existing Open Repository repository is suitable.



    , combined with these repositories being tied to very specific projects and not having a generic top-level repository.



    In the case at hand: the CTI TC can create an OASIS Open Repository described as "generic":  that is your choice.   I suppose you could also characterize some new OASIS Open Repository
    as "top-level" (notionally) if the TC members wanted to do that.


     




    Imagine a non-TC member has some brand new code they want to contribute, but it does not fall into any of these existing open repository categories, and we have no "generic" type of repository. They can not make a new repository, or even motion to make one,
    as they are not a TC member. They're stuck. The only way they could donate this code, would be to try to proxy through another TC member to get the repository created for them to commit it to. I strongly suspect that instead of that hassle they would just
    put it up on their own Github.



     


    Thanks for the clarification via examples.  I'll certainly raise the issue with Staff.  All such suggestions for improvement are welcome.


     


    Kindest regards and best wishes,


     


    - Robin


     


     




    -
    Jason Keirstead
    STSM, Product Architect, Security Intelligence, IBM Security Systems
    www.ibm.com/security
    www.securityintelligence.com

    Without data, all you are is just another person with an opinion - Unknown


    Robin Cover ---09/29/2016
    09:28:30 AM---On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:

    From: Robin Cover < robin@oasis-open.org >
    To: Jason Keirstead/CanEast/IBM@IBMCA
    Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >,
    OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org >
    Date: 09/29/2016 09:28 AM
    Subject: Re: [cti] Status of CTI OASIS Open Repositories
    Sent by: < cti@lists.oasis-open.org >








    On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:


    I hear what you are saying and there are definitely pros and cons to having some more generic repositories - but I am trying to envision the near future where we will hopefully have a whole bunch of various code contributions
    from vendors, members and hopefully non-members alike. This is just my opinion of course, but I think we should try to make the process to contribute code to the TC as light-weight as possible, to encourage people to contribute to our open repositories vs.
    just throw it up on their own Github account - as if they do that, then IPR and access is not as assured. Having to make a motion to create a new repository every time someone wants to contribute some new code, is a fairly heavyweight process in my opinion.
    It also means that only TC members can contribute any "new things", because the public can't trigger a vote on making a new repository - so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they
    proxy through a member).

    Jason, I'll raise the matter of requiring a motion/ballot with Staff.  We probably want some kind of confirmation from the TC Chairs(s) -- indicating that there was consensus on the key elements of the request (name, Maintainers,
    choice of FOSS license, etc)

    Re:
    > a whole bunch of various code contributions from vendors, members and hopefully non-members alike

    That sounds great, and OASIS Open Repositories are intended to support that.   It's a TC decision whether you want more or fewer repositories. It's a TC decision as to whether the repos are described as "generic" or having closely
    defined focus.

    I don't quite understand your meaning here:

    "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)"

    For the OASIS Open Repositories, once the repo is created, anyone from "the public" (non-TC member) can be a full participant, including Maintainer, per consensus.  They can contribute "new things" in the same way as anyone can
    contribute new things to any GitHub public repository.  Perhaps I misunderstand your concern....

    I have assumed, maybe incorrectly, that your mention of a new repository (additional to those reported by Greg Back [1]) meant you want a new OASIS Open Repository (  https://www.oasis-open.org/resources/open-repositories
    )

    - Robin


    [1]

    cti-stix2-json-schemas
    cti-pattern-validator
    cti-marking-prototype
    cti-stix-visualization
    cti-stix-validator
    cti-documentation
    cti-cybox3-json-schemas

     


    -
    Jason Keirstead
    STSM, Product Architect, Security Intelligence, IBM Security Systems
    www.ibm.com/security
    www.securityintelligence.com

    Without data, all you are is just another person with an opinion - Unknown


    Robin
    Cover ---09/28/2016 10:35:01 PM---Jason, The decision about creating something like "stix-tools" is (of course) a

    From: Robin Cover < robin@oasis-open.org >
    To: Jason Keirstead/CanEast/IBM@IBMCA
    Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >,
    Robin Cover < robin@oasis-open.org >
    Date: 09/28/2016 10:35 PM
    Subject: Re: [cti] Status of CTI OASIS Open Repositories
    Sent by: < cti@lists.oasis-open.org >









    Jason,

    The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race.

    Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository.

    One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent)  design that uses folders within a single repository.   Using separate repos means less work (design work, workday-work)
    when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo.  Just use one taxonomy of types/labels without namespace worries.  And: you can five write privs
    to relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects...

    But as always: it's up to the TC, and I am no expert here.

    - Robin

    On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:


    Hello all;

    IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement.

    It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets?

    --
    Sent from my mobile device, please excuse any typos.

    Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories ---





    From:


    "Kirillov, Ivan A." < ikirillov@mitre.org >




    To:


    "Back, Greg" < gback@mitre.org >,
    cti@lists.oasis-open.org




    Date:


    Wed, Sep 28, 2016 2:09 PM




    Subject:


    Re: [cti] Status of CTI OASIS Open Repositories











    Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-)

    Regards,
    Ivan

    On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org  on behalf of
    Back, Greg" < cti@lists.oasis-open.org  on behalf of
    gback@mitre.org > wrote:

    >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS.

    >
    >- cti-stix2-json-schemas
    >- cti-pattern-validator
    >- cti-marking-prototype
    >- cti-stix-visualization
    >- cti-stix-validator
    >
    >There are two other repositories that exist, but do not (yet) have any content:
    >
    >- cti-documentation
    >- cti-cybox3-json-schemas
    >
    >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but
    in order to do so, you must sign a Contributor License Agreement (CLA): https://www.oasis-open.org/resources/open-repositories/cla  .
    This applies *even to TC members*.
    >
    >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to
    respond to this email if you have questions about the process, etc.
    >
    >You can find the repositories here:
    https://github.com/oasis-open  
    >
    >Thanks,
    >
    >Greg Back
    >MITRE
    >
    >---------------------------------------------------------------------
    >To unsubscribe from this mail list, you must leave the OASIS TC that

    >generates this mail.  Follow this link to all your TCs in OASIS at:
    > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php  
    >




    --
     







     

    --


     





















  • 13.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-05-2016 13:04
    Mark, I'll try to track with the conversation referenced below.  We (OASIS) did consider several alternatives when designing the current plans for OASIS Open Repositories and (distinct from) GitHub Repos for TC work. Initially, two questions for you 1. Can you clarify that you make reference to GitHub repos that are used only by TC Members, governed by all OASIS policies (IPR, TC Process...) as opposed to "open" repositories that allow participation by anyone, via CLA, under open source licensing ? 2. Can you explain why GitHub Project Pages will not work for the TCs?  What features of Organization Pages are lacking in Project Pages [1]? 3. Are you proposing that the repos you envision are NOT governed by OASIS rules?  Foe example, you talk about repo deletion as a desirable feature ("t he operating rules can be superseded by a ballot on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted.."  OASIS rules prohibit deletion of resources created by TC members [2] Comment: If you principal concern is about "ballots" (" A set of operating rules for managing repos that does NOT require a ballot"), then I think there is room within OASIS practice (and policy), perhaps with a few clarifications and updates, to allow most of what a TC wants to do -- without ballot.  The matter of requiring a ballot for TC creation was raised earlier: under current OASIS rules, a "ballot" is not required for creation of an OASIS Open Repository or for the creation of a TC GitHub repo (repository for TC CHartered work).  What's required is meeting minutes.  We can clarify that further. That's all for now. Thanks, - Robin [1]   https://help.github.com/articles/user-organization-and-project-pages/#project-pages [2]   http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#resourcePermanence Resource Permanence As part of the OASIS institutional commitment to transparency, openness, accountability, and public auditability, resources published in the OASIS Library, TC Document Repository, and other venues must not be deleted or otherwise altered. Resources may be revised, but all revisions are retained. With the exception of resources identified by "latest version" URI aliases, content instantiated as regular files and directories must not be over-written, replaced, renamed, or removed. TC Members are expected to follow this rule even in cases where a collaboration tool (by some means) might allow resource deletion or silent alteration. On Wed, Oct 5, 2016 at 7:30 AM, Mark Davidson < mdavidson@soltra.com > wrote: I realize this might go against the grain for some, but maybe we should talk about the organization of GitHub repos on the next working call. Personally, having one OASIS organization for _all_ GitHub repos is going to make tracking the work of any single TC more difficult. In addition, one OASIS organization prevents individual TCs from having *. github.io pages, which the STIX/TAXII group has made good use of in the past. I’d like it if we could consider a method that would provide the necessary governance AND make the management of GitHub repos a little less cumbersome.   I don’t know if it’s feasible, but I’d be interested in exploring a structure that has the following properties: ·          A GitHub organization for the CTI TC (e.g., github.com/oasis-cti-tc/ ) ·          All CTI TC repos fall under the OASIS-CTI-TC GitHub Org ·          A set of operating rules for managing repos that does NOT require a ballot. Possible operating rules: o     New repos require sponsorship by a co-chair and sign-off by the TC chair o     Repo maintainer has some authority over who has which rights o     Any part of the operating rules can be superseded by a ballot on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted) ·          Other considerations?   Basically, my goal would be to free us up a bit in terms of repo management, while staying true to the intent of participating in OASIS. What do people think?   Thank you. -Mark   From: < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org > Date: Tuesday, October 4, 2016 at 7:02 PM To: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com > Cc: Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories   Another resource on submodules   "Working with submodules" (February 01, 2016) https://github.com/blog/2104- working-with-submodules   -rcc   On Tue, Oct 4, 2016 at 3:56 PM, Ted Bedwell (tebedwel) < tebedwel@cisco.com > wrote: For the other git neophytes out there: https://git-scm.com/book/en/ v2/Git-Tools-Submodules http://blogs.atlassian.com/ 2013/03/git-submodules- workflows-tips/   This seems like a viable approach.   From: < cti@lists.oasis-open.org > on behalf of Terry MacDonald < terry.macdonald@cosive.com > Date: Tuesday, October 4, 2016 at 3:19 PM To: "Bret Jordan (CS)" < Bret_Jordan@symantec.com > Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories   Couldn't we do a git repo containing submodules? Then each tool can have its own git repo, and it can be linked a submodules into the overall tools collection repo. This then makes it easy for everyone to get a copy of all three rows from one place, and yet we avoid the problems with many different people who only need access to parts of the git tree... Cheers Terry MacDonald Cosive   On 4 Oct. 2016 9:09 am, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote: The problem with all of this is that it is not a collection of repos, but rather specific repos.  Including multiple projects in a single repo is considered "bad form".  Yes, you can do funky things with TAGS and you can even use different directories in the same repo.  But that kind of break the git model.  So instead of OASIS creating a oasis-open project with a bunch of arrant TC repos underneath, it seems like OASIS should setup a TC specific "projects".  Then the TC can create as many repos on the project that it wants.   Bret From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org > Sent: Thursday, September 29, 2016 8:28:43 AM To: Jason Keirstead Cc: Kirillov, Ivan A.; Back, Greg; OASIS CTI TC Discussion List; Robin Cover Subject: Re: [cti] Status of CTI OASIS Open Repositories   On Thu, Sep 29, 2016 at 9:14 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: RE " I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" " It is basically tied back to the need, currently, to be a TC member and make a motion if you want to make a new repository OK, I understand.  I'll raise the issue with Staff: can/should we support some means whereby a non-TC Member can easily make request for a new OASIS Open Repository where it's perceived that no existing Open Repository repository is suitable. , combined with these repositories being tied to very specific projects and not having a generic top-level repository. In the case at hand: the CTI TC can create an OASIS Open Repository described as "generic":  that is your choice.   I suppose you could also characterize some new OASIS Open Repository as "top-level" (notionally) if the TC members wanted to do that.   Imagine a non-TC member has some brand new code they want to contribute, but it does not fall into any of these existing open repository categories, and we have no "generic" type of repository. They can not make a new repository, or even motion to make one, as they are not a TC member. They're stuck. The only way they could donate this code, would be to try to proxy through another TC member to get the repository created for them to commit it to. I strongly suspect that instead of that hassle they would just put it up on their own Github.   Thanks for the clarification via examples.  I'll certainly raise the issue with Staff.  All such suggestions for improvement are welcome.   Kindest regards and best wishes,   - Robin     - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/29/2016 09:28:30 AM---On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/29/2016 09:28 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I hear what you are saying and there are definitely pros and cons to having some more generic repositories - but I am trying to envision the near future where we will hopefully have a whole bunch of various code contributions from vendors, members and hopefully non-members alike. This is just my opinion of course, but I think we should try to make the process to contribute code to the TC as light-weight as possible, to encourage people to contribute to our open repositories vs. just throw it up on their own Github account - as if they do that, then IPR and access is not as assured. Having to make a motion to create a new repository every time someone wants to contribute some new code, is a fairly heavyweight process in my opinion. It also means that only TC members can contribute any "new things", because the public can't trigger a vote on making a new repository - so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member). Jason, I'll raise the matter of requiring a motion/ballot with Staff.  We probably want some kind of confirmation from the TC Chairs(s) -- indicating that there was consensus on the key elements of the request (name, Maintainers, choice of FOSS license, etc) Re: > a whole bunch of various code contributions from vendors, members and hopefully non-members alike That sounds great, and OASIS Open Repositories are intended to support that.   It's a TC decision whether you want more or fewer repositories. It's a TC decision as to whether the repos are described as "generic" or having closely defined focus. I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" For the OASIS Open Repositories, once the repo is created, anyone from "the public" (non-TC member) can be a full participant, including Maintainer, per consensus.  They can contribute "new things" in the same way as anyone can contribute new things to any GitHub public repository.  Perhaps I misunderstand your concern.... I have assumed, maybe incorrectly, that your mention of a new repository (additional to those reported by Greg Back [1]) meant you want a new OASIS Open Repository (  https://www.oasis-open.org/ resources/open-repositories ) - Robin [1] cti-stix2-json-schemas cti-pattern-validator cti-marking-prototype cti-stix-visualization cti-stix-validator cti-documentation cti-cybox3-json-schemas   - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/28/2016 10:35:01 PM---Jason, The decision about creating something like "stix-tools" is (of course) a From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/28/2016 10:35 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > Jason, The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race. Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository. One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent)  design that uses folders within a single repository.   Using separate repos means less work (design work, workday-work) when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo.  Just use one taxonomy of types/labels without namespace worries.  And: you can five write privs to relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects... But as always: it's up to the TC, and I am no expert here. - Robin On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Hello all; IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement. It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets? -- Sent from my mobile device, please excuse any typos. Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories --- From: "Kirillov, Ivan A." < ikirillov@mitre.org > To: "Back, Greg" < gback@mitre.org >, cti@lists.oasis-open.org Date: Wed, Sep 28, 2016 2:09 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-) Regards, Ivan On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org  on behalf of Back, Greg" < cti@lists.oasis-open.org  on behalf of gback@mitre.org > wrote: >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS. > >- cti-stix2-json-schemas >- cti-pattern-validator >- cti-marking-prototype >- cti-stix-visualization >- cti-stix-validator > >There are two other repositories that exist, but do not (yet) have any content: > >- cti-documentation >- cti-cybox3-json-schemas > >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor License Agreement (CLA): https://www.oasis-open.org/ resources/open-repositories/ cla  . This applies *even to TC members*. > >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions about the process, etc. > >You can find the repositories here: https://github.com/oasis-open   > >Thanks, > >Greg Back >MITRE > >----------------------------- ------------------------------ ---------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/ apps/org/workgroup/portal/my_ workgroups.php   > --     --   -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783


  • 14.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-05-2016 13:54




    Robin,
     
    My primary concern is that balloting seems slightly more heavyweight of a process than necessary for governing the GitHub Repos. To your main point, I do think there is a way to improve
    the process to a mutually agreeable end state.
     
    You raise some good questions, and I’d like to address them directly:
     
    > 1. Can you clarify that you make reference to GitHub repos that are used only by TC Members, governed by all OASIS policies (IPR, TC Process...) as opposed to "open" repositories that
    allow participation by anyone, via CLA, under open source licensing ?
     
    I am talking about GitHub repos that are governed by OASIS policies. I am under the impression that these repositories can be used by anyone.
     
    > 2. Can you explain why GitHub Project Pages will not work for the TCs?  What features of Organization Pages are lacking in Project Pages [1]?
     
    There’s two reasons I’d like to consider one GitHub organization or the CTI TC (vs one GitHub org for all things OASIS)
     
    First - User, Project, and Organization pages differ in terms of the Hostname/URL that GitHub provides. Personally, I feel pretty strongly that our websites should have names that are short
    and easy to remember. In my opinion, e.g., https://oasis-open.github.io/cti-documentation just will not stick with people the same way that https://stixproject.github.io sticks with people. There are other ways to achieve this – including a custom domain [1],
    but we should figure it out IMO.
     
    Second – The way people use GitHub, it (IMO) just makes more sense for related repos to be under a single GitHub organization and for unrelated repos to be located somewhere else. I’m interested
    in what other people think here (I’m just one opinon), but I’m strongly in favor of having one GitHub org for the CTI TC.
     
    > 3. Are you proposing that the repos you envision are NOT governed by OASIS rules?
     
    My apologies – I picked a bad example (repo deletion). My goal is a better process. In no way do I intend to circumvent or avoid the rules that we all agreed to support by joining OASIS.
     
    Thank you.
    -Mark
     
    [1] https://help.github.com/articles/using-a-custom-domain-with-github-pages/
     

    From:
    Robin Cover <robin@oasis-open.org>
    Date: Wednesday, October 5, 2016 at 9:04 AM
    To: Mark Davidson <mdavidson@soltra.com>
    Cc: "Ted Bedwell (tebedwel)" <tebedwel@cisco.com>, Terry MacDonald <terry.macdonald@cosive.com>, "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "Kirillov,
    Ivan A." <ikirillov@mitre.org>, "Back, Greg" <gback@mitre.org>, Robin Cover <robin@oasis-open.org>
    Subject: Re: [cti] Status of CTI OASIS Open Repositories


     


    Mark,

     


    I'll try to track with the conversation referenced below.  We (OASIS) did consider several alternatives when designing the current plans for OASIS Open Repositories and (distinct from) GitHub Repos for TC work.


     


    Initially, two questions for you


     


    1. Can you clarify that you make reference to GitHub repos that are used only by TC Members, governed by all OASIS policies (IPR, TC Process...) as opposed to "open" repositories that allow participation by anyone, via CLA, under open source
    licensing ?


     


    2. Can you explain why GitHub Project Pages will not work for the TCs?  What features of Organization Pages are lacking in Project Pages [1]?


     


    3. Are you proposing that the repos you envision are NOT governed by OASIS rules?  Foe example, you talk about repo deletion as a desirable feature ("t he operating rules can be superseded
    by a ballot on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted.."  OASIS rules prohibit deletion of resources created by TC members [2]


     


    Comment:


     


    If you principal concern is about "ballots" (" A set of operating rules for managing repos that does NOT require a ballot"), then I think there is room within OASIS practice (and policy),
    perhaps with a few clarifications and updates, to allow most of what a TC wants to do -- without ballot.  The matter of requiring a ballot for TC creation was raised earlier: under current OASIS rules, a "ballot" is not required for creation of an OASIS Open
    Repository or for the creation of a TC GitHub repo (repository for TC CHartered work).  What's required is meeting minutes.  We can clarify that further.


     


    That's all for now.


     


    Thanks,


     


    - Robin


     


    [1]   https://help.github.com/articles/user-organization-and-project-pages/#project-pages


     


     


    [2]   http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#resourcePermanence


     



    Resource Permanence


    As part of the OASIS institutional commitment to transparency, openness, accountability, and public auditability, resources published in the OASIS Library, TC Document Repository, and other venues must not be deleted or otherwise altered.
    Resources may be revised, but all revisions are retained. With the exception of resources identified by "latest version" URI aliases, content instantiated as regular files and directories must not be over-written, replaced, renamed, or removed. TC Members
    are expected to follow this rule even in cases where a collaboration tool (by some means) might allow resource deletion or silent alteration.



     


     

    On Wed, Oct 5, 2016 at 7:30 AM, Mark Davidson < mdavidson@soltra.com > wrote:



    I realize this might go against the grain for some, but maybe we should talk about the organization of GitHub repos on the next
    working call. Personally, having one OASIS organization for _all_ GitHub repos is going to make tracking the work of any single TC more difficult. In addition, one OASIS organization prevents individual TCs from having *. github.io
    pages, which the STIX/TAXII group has made good use of in the past. I’d like it if we could consider a method that would provide the necessary governance AND make the management of GitHub repos a little less cumbersome.
     
    I don’t know if it’s feasible, but I’d be interested in exploring a structure that has the following properties:
    ·         
    A GitHub organization for the CTI TC (e.g.,
    github.com/oasis-cti-tc/ )
    ·         
    All CTI TC repos fall under the OASIS-CTI-TC GitHub Org
    ·         
    A set of operating rules for managing repos that does NOT require a ballot. Possible operating rules:
    o    
    New repos require sponsorship by a co-chair and sign-off by the TC chair
    o    
    Repo maintainer has some authority over who has which rights
    o    
    Any part of the operating rules can be superseded by a ballot on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted)
    ·         
    Other considerations?
     
    Basically, my goal would be to free us up a bit in terms of repo management, while staying true to the intent of participating
    in OASIS. What do people think?
     
    Thank you.
    -Mark
     

    From:
    < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org >
    Date: Tuesday, October 4, 2016 at 7:02 PM
    To: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >
    Cc: Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org "
    < cti@lists.oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >,
    "Back, Greg" < gback@mitre.org >
    Subject: Re: [cti] Status of CTI OASIS Open Repositories


     


    Another resource on submodules


     


    "Working with submodules" (February 01, 2016)


    https://github.com/blog/2104-working-with-submodules


     


    -rcc


     

    On Tue, Oct 4, 2016 at 3:56 PM, Ted Bedwell (tebedwel) < tebedwel@cisco.com > wrote:



    For the other git neophytes out there:
    https://git-scm.com/book/en/v2/Git-Tools-Submodules
    http://blogs.atlassian.com/2013/03/git-submodules-workflows-tips/
     
    This seems like a viable approach.

     


    From:
    < cti@lists.oasis-open.org > on behalf of Terry MacDonald < terry.macdonald@cosive.com >
    Date: Tuesday, October 4, 2016 at 3:19 PM
    To: "Bret Jordan (CS)" < Bret_Jordan@symantec.com >
    Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org >,
    Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >
    Subject: Re: [cti] Status of CTI OASIS Open Repositories


     

    Couldn't we do a git repo containing submodules? Then each tool can have its own git repo, and it can be linked a submodules into the overall tools collection repo.

    This then makes it easy for everyone to get a copy of all three rows from one place, and yet we avoid the problems with many different people who only need access to parts of the git tree...
    Cheers
    Terry MacDonald
    Cosive

     

    On 4 Oct. 2016 9:09 am, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote:



    The problem with all of this is that it is not a collection of repos, but rather specific repos.  Including multiple projects in a single repo is considered "bad form".  Yes, you can do funky things with TAGS
    and you can even use different directories in the same repo.  But that kind of break the git model.  So instead of OASIS creating a oasis-open project with a bunch of arrant TC repos underneath, it seems like OASIS should setup a TC specific "projects".  Then
    the TC can create as many repos on the project that it wants.
     
    Bret





    From:
    cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org >
    Sent: Thursday, September 29, 2016 8:28:43 AM
    To: Jason Keirstead
    Cc: Kirillov, Ivan A.; Back, Greg; OASIS CTI TC Discussion List; Robin Cover
    Subject: Re: [cti] Status of CTI OASIS Open Repositories

     






    On Thu, Sep 29, 2016 at 9:14 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:


    RE " I don't quite understand your meaning here:


    "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" "

    It is basically tied back to the need, currently, to be a TC member and make a motion if you want to make a new repository



    OK, I understand.  I'll raise the issue with Staff: can/should we support some means whereby a non-TC Member can easily make request for a new OASIS Open Repository where it's perceived
    that no existing Open Repository repository is suitable.



    , combined with these repositories being tied to very specific projects and not having a generic top-level repository.



    In the case at hand: the CTI TC can create an OASIS Open Repository described as "generic":  that is your choice.   I suppose you could also characterize some new OASIS Open Repository
    as "top-level" (notionally) if the TC members wanted to do that.


     




    Imagine a non-TC member has some brand new code they want to contribute, but it does not fall into any of these existing open repository categories, and we have no "generic" type of repository. They can not make a new repository, or even motion to make one,
    as they are not a TC member. They're stuck. The only way they could donate this code, would be to try to proxy through another TC member to get the repository created for them to commit it to. I strongly suspect that instead of that hassle they would just
    put it up on their own Github.



     


    Thanks for the clarification via examples.  I'll certainly raise the issue with Staff.  All such suggestions for improvement are welcome.


     


    Kindest regards and best wishes,


     


    - Robin


     


     




    -
    Jason Keirstead
    STSM, Product Architect, Security Intelligence, IBM Security Systems
    www.ibm.com/security
    www.securityintelligence.com

    Without data, all you are is just another person with an opinion - Unknown


    Robin
    Cover ---09/29/2016 09:28:30 AM---On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:

    From: Robin Cover < robin@oasis-open.org >
    To: Jason Keirstead/CanEast/IBM@IBMCA
    Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >,
    OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org >
    Date: 09/29/2016 09:28 AM
    Subject: Re: [cti] Status of CTI OASIS Open Repositories
    Sent by: < cti@lists.oasis-open.org >










    On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:


    I hear what you are saying and there are definitely pros and cons to having some more generic repositories - but I am trying to envision the near future where we will hopefully have a whole bunch of various code contributions
    from vendors, members and hopefully non-members alike. This is just my opinion of course, but I think we should try to make the process to contribute code to the TC as light-weight as possible, to encourage people to contribute to our open repositories vs.
    just throw it up on their own Github account - as if they do that, then IPR and access is not as assured. Having to make a motion to create a new repository every time someone wants to contribute some new code, is a fairly heavyweight process in my opinion.
    It also means that only TC members can contribute any "new things", because the public can't trigger a vote on making a new repository - so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they
    proxy through a member).

    Jason, I'll raise the matter of requiring a motion/ballot with Staff.  We probably want some kind of confirmation from the TC Chairs(s) -- indicating that there was consensus on the key elements of the request (name, Maintainers,
    choice of FOSS license, etc)

    Re:
    > a whole bunch of various code contributions from vendors, members and hopefully non-members alike

    That sounds great, and OASIS Open Repositories are intended to support that.   It's a TC decision whether you want more or fewer repositories. It's a TC decision as to whether the repos are described as "generic" or having closely
    defined focus.

    I don't quite understand your meaning here:

    "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)"

    For the OASIS Open Repositories, once the repo is created, anyone from "the public" (non-TC member) can be a full participant, including Maintainer, per consensus.  They can contribute "new things" in the same way as anyone can
    contribute new things to any GitHub public repository.  Perhaps I misunderstand your concern....

    I have assumed, maybe incorrectly, that your mention of a new repository (additional to those reported by Greg Back [1]) meant you want a new OASIS Open Repository (  https://www.oasis-open.org/resources/open-repositories
    )

    - Robin


    [1]

    cti-stix2-json-schemas
    cti-pattern-validator
    cti-marking-prototype
    cti-stix-visualization
    cti-stix-validator
    cti-documentation
    cti-cybox3-json-schemas

     


    -
    Jason Keirstead
    STSM, Product Architect, Security Intelligence, IBM Security Systems
    www.ibm.com/security
    www.securityintelligence.com

    Without data, all you are is just another person with an opinion - Unknown


    Robin
    Cover ---09/28/2016 10:35:01 PM---Jason, The decision about creating something like "stix-tools" is (of course) a

    From: Robin Cover < robin@oasis-open.org >
    To: Jason Keirstead/CanEast/IBM@IBMCA
    Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >,
    Robin Cover < robin@oasis-open.org >
    Date: 09/28/2016 10:35 PM
    Subject: Re: [cti] Status of CTI OASIS Open Repositories
    Sent by: < cti@lists.oasis-open.org >











    Jason,

    The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race.

    Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository.

    One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent)  design that uses folders within a single repository.   Using separate repos means less work (design work, workday-work)
    when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo.  Just use one taxonomy of types/labels without namespace worries.  And: you can five write privs
    to relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects...

    But as always: it's up to the TC, and I am no expert here.

    - Robin

    On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:


    Hello all;

    IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement.

    It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets?

    --
    Sent from my mobile device, please excuse any typos.

    Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories ---





    From:


    "Kirillov, Ivan A." < ikirillov@mitre.org >




    To:


    "Back, Greg" < gback@mitre.org >,
    cti@lists.oasis-open.org




    Date:


    Wed, Sep 28, 2016 2:09 PM




    Subject:


    Re: [cti] Status of CTI OASIS Open Repositories













    Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-)

    Regards,
    Ivan

    On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org  on behalf of
    Back, Greg" < cti@lists.oasis-open.org  on behalf of
    gback@mitre.org > wrote:

    >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS.

    >
    >- cti-stix2-json-schemas
    >- cti-pattern-validator
    >- cti-marking-prototype
    >- cti-stix-visualization
    >- cti-stix-validator
    >
    >There are two other repositories that exist, but do not (yet) have any content:
    >
    >- cti-documentation
    >- cti-cybox3-json-schemas
    >
    >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but
    in order to do so, you must sign a Contributor License Agreement (CLA): https://www.oasis-open.org/resources/open-repositories/cla  .
    This applies *even to TC members*.
    >
    >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to
    respond to this email if you have questions about the process, etc.
    >
    >You can find the repositories here:
    https://github.com/oasis-open  
    >
    >Thanks,
    >
    >Greg Back
    >MITRE
    >
    >---------------------------------------------------------------------
    >To unsubscribe from this mail list, you must leave the OASIS TC that

    >generates this mail.  Follow this link to all your TCs in OASIS at:
    > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php  
    >




    --

     







     

    --


     























     

    --

    Robin Cover
    OASIS, Director of Information Services
    Editor, Cover Pages and XML Daily Newslink
    Email: robin@oasis-open.org
    Staff bio:
    http://www.oasis-open.org/people/staff/robin-cover
    Cover Pages: http://xml.coverpages.org/
    Newsletter:
    http://xml.coverpages.org/newsletterArchive.html
    Tel: +1 972-296-1783









  • 15.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-05-2016 14:47
    The other aspect of this that should be considered by OASIS IMO, and why Mark's plan is very good - is that as these open repositories grow, it is going to quickly become a management headache under the current structure, because it lacks the ability to break things down by TC. Image our TC has 20 repos, another has 10, another has 15... quickly, when one goes to https://github.com/oasis-open/ , they will be confronted with a list of hundreds of repositories... as a user, how do I quickly filter this list to only contain only CTI TC items (or any other TC)? Whereas, if we use Mark's plan, all of the repos for a given TC are in one place, and it is easy as a user to find them on Github. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Mark Davidson ---10/05/2016 10:53:48 AM---Robin, My primary concern is that balloting seems slightly more heavyweight of a process than necess From: Mark Davidson <mdavidson@soltra.com> To: Robin Cover <robin@oasis-open.org> Cc: "Ted Bedwell (tebedwel)" <tebedwel@cisco.com>, Terry MacDonald <terry.macdonald@cosive.com>, "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Jason Keirstead/CanEast/IBM@IBMCA, "Kirillov, Ivan A." <ikirillov@mitre.org>, "Back, Greg" <gback@mitre.org> Date: 10/05/2016 10:53 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: <cti@lists.oasis-open.org> Robin, My primary concern is that balloting seems slightly more heavyweight of a process than necessary for governing the GitHub Repos. To your main point, I do think there is a way to improve the process to a mutually agreeable end state. You raise some good questions, and I’d like to address them directly: > 1. Can you clarify that you make reference to GitHub repos that are used only by TC Members, governed by all OASIS policies (IPR, TC Process...) as opposed to "open" repositories that allow participation by anyone, via CLA, under open source licensing ? I am talking about GitHub repos that are governed by OASIS policies. I am under the impression that these repositories can be used by anyone. > 2. Can you explain why GitHub Project Pages will not work for the TCs? What features of Organization Pages are lacking in Project Pages [1]? There’s two reasons I’d like to consider one GitHub organization or the CTI TC (vs one GitHub org for all things OASIS) First - User, Project, and Organization pages differ in terms of the Hostname/URL that GitHub provides. Personally, I feel pretty strongly that our websites should have names that are short and easy to remember. In my opinion, e.g., https://oasis-open.github.io/cti-documentation just will not stick with people the same way that https://stixproject.github.io sticks with people. There are other ways to achieve this – including a custom domain [1], but we should figure it out IMO. Second – The way people use GitHub, it (IMO) just makes more sense for related repos to be under a single GitHub organization and for unrelated repos to be located somewhere else. I’m interested in what other people think here (I’m just one opinon), but I’m strongly in favor of having one GitHub org for the CTI TC. > 3. Are you proposing that the repos you envision are NOT governed by OASIS rules? My apologies – I picked a bad example (repo deletion). My goal is a better process. In no way do I intend to circumvent or avoid the rules that we all agreed to support by joining OASIS. Thank you. -Mark [1] https://help.github.com/articles/using-a-custom-domain-with-github-pages/ From: Robin Cover <robin@oasis-open.org> Date: Wednesday, October 5, 2016 at 9:04 AM To: Mark Davidson <mdavidson@soltra.com> Cc: "Ted Bedwell (tebedwel)" <tebedwel@cisco.com>, Terry MacDonald <terry.macdonald@cosive.com>, "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "Kirillov, Ivan A." <ikirillov@mitre.org>, "Back, Greg" <gback@mitre.org>, Robin Cover <robin@oasis-open.org> Subject: Re: [cti] Status of CTI OASIS Open Repositories Mark, I'll try to track with the conversation referenced below. We (OASIS) did consider several alternatives when designing the current plans for OASIS Open Repositories and (distinct from) GitHub Repos for TC work. Initially, two questions for you 1. Can you clarify that you make reference to GitHub repos that are used only by TC Members, governed by all OASIS policies (IPR, TC Process...) as opposed to "open" repositories that allow participation by anyone, via CLA, under open source licensing ? 2. Can you explain why GitHub Project Pages will not work for the TCs? What features of Organization Pages are lacking in Project Pages [1]? 3. Are you proposing that the repos you envision are NOT governed by OASIS rules? Foe example, you talk about repo deletion as a desirable feature ("t he operating rules can be superseded by a ballot on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted.." OASIS rules prohibit deletion of resources created by TC members [2] Comment: If you principal concern is about "ballots" (" A set of operating rules for managing repos that does NOT require a ballot"), then I think there is room within OASIS practice (and policy), perhaps with a few clarifications and updates, to allow most of what a TC wants to do -- without ballot. The matter of requiring a ballot for TC creation was raised earlier: under current OASIS rules, a "ballot" is not required for creation of an OASIS Open Repository or for the creation of a TC GitHub repo (repository for TC CHartered work). What's required is meeting minutes. We can clarify that further. That's all for now. Thanks, - Robin [1] https://help.github.com/articles/user-organization-and-project-pages/#project-pages [2] http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#resourcePermanence Resource Permanence As part of the OASIS institutional commitment to transparency, openness, accountability, and public auditability, resources published in the OASIS Library, TC Document Repository, and other venues must not be deleted or otherwise altered. Resources may be revised, but all revisions are retained. With the exception of resources identified by "latest version" URI aliases, content instantiated as regular files and directories must not be over-written, replaced, renamed, or removed. TC Members are expected to follow this rule even in cases where a collaboration tool (by some means) might allow resource deletion or silent alteration. On Wed, Oct 5, 2016 at 7:30 AM, Mark Davidson < mdavidson@soltra.com > wrote: I realize this might go against the grain for some, but maybe we should talk about the organization of GitHub repos on the next working call. Personally, having one OASIS organization for _all_ GitHub repos is going to make tracking the work of any single TC more difficult. In addition, one OASIS organization prevents individual TCs from having *. github.io pages, which the STIX/TAXII group has made good use of in the past. I’d like it if we could consider a method that would provide the necessary governance AND make the management of GitHub repos a little less cumbersome. I don’t know if it’s feasible, but I’d be interested in exploring a structure that has the following properties: · A GitHub organization for the CTI TC (e.g., github.com/oasis-cti-tc/ ) · All CTI TC repos fall under the OASIS-CTI-TC GitHub Org · A set of operating rules for managing repos that does NOT require a ballot. Possible operating rules: o New repos require sponsorship by a co-chair and sign-off by the TC chair o Repo maintainer has some authority over who has which rights o Any part of the operating rules can be superseded by a ballot on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted) · Other considerations? Basically, my goal would be to free us up a bit in terms of repo management, while staying true to the intent of participating in OASIS. What do people think? Thank you. -Mark From: < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org > Date: Tuesday, October 4, 2016 at 7:02 PM To: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com > Cc: Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories Another resource on submodules "Working with submodules" (February 01, 2016) https://github.com/blog/2104-working-with-submodules -rcc On Tue, Oct 4, 2016 at 3:56 PM, Ted Bedwell (tebedwel) < tebedwel@cisco.com > wrote: For the other git neophytes out there: https://git-scm.com/book/en/v2/Git-Tools-Submodules http://blogs.atlassian.com/2013/03/git-submodules-workflows-tips/ This seems like a viable approach. From: < cti@lists.oasis-open.org > on behalf of Terry MacDonald < terry.macdonald@cosive.com > Date: Tuesday, October 4, 2016 at 3:19 PM To: "Bret Jordan (CS)" < Bret_Jordan@symantec.com > Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories Couldn't we do a git repo containing submodules? Then each tool can have its own git repo, and it can be linked a submodules into the overall tools collection repo. This then makes it easy for everyone to get a copy of all three rows from one place, and yet we avoid the problems with many different people who only need access to parts of the git tree... Cheers Terry MacDonald Cosive On 4 Oct. 2016 9:09 am, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote: The problem with all of this is that it is not a collection of repos, but rather specific repos. Including multiple projects in a single repo is considered "bad form". Yes, you can do funky things with TAGS and you can even use different directories in the same repo. But that kind of break the git model. So instead of OASIS creating a oasis-open project with a bunch of arrant TC repos underneath, it seems like OASIS should setup a TC specific "projects". Then the TC can create as many repos on the project that it wants. Bret From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org > Sent: Thursday, September 29, 2016 8:28:43 AM To: Jason Keirstead Cc: Kirillov, Ivan A.; Back, Greg; OASIS CTI TC Discussion List; Robin Cover Subject: Re: [cti] Status of CTI OASIS Open Repositories On Thu, Sep 29, 2016 at 9:14 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: RE " I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" " It is basically tied back to the need, currently, to be a TC member and make a motion if you want to make a new repository OK, I understand. I'll raise the issue with Staff: can/should we support some means whereby a non-TC Member can easily make request for a new OASIS Open Repository where it's perceived that no existing Open Repository repository is suitable. , combined with these repositories being tied to very specific projects and not having a generic top-level repository. In the case at hand: the CTI TC can create an OASIS Open Repository described as "generic": that is your choice. I suppose you could also characterize some new OASIS Open Repository as "top-level" (notionally) if the TC members wanted to do that. Imagine a non-TC member has some brand new code they want to contribute, but it does not fall into any of these existing open repository categories, and we have no "generic" type of repository. They can not make a new repository, or even motion to make one, as they are not a TC member. They're stuck. The only way they could donate this code, would be to try to proxy through another TC member to get the repository created for them to commit it to. I strongly suspect that instead of that hassle they would just put it up on their own Github. Thanks for the clarification via examples. I'll certainly raise the issue with Staff. All such suggestions for improvement are welcome. Kindest regards and best wishes, - Robin - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/29/2016 09:28:30 AM---On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/29/2016 09:28 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I hear what you are saying and there are definitely pros and cons to having some more generic repositories - but I am trying to envision the near future where we will hopefully have a whole bunch of various code contributions from vendors, members and hopefully non-members alike. This is just my opinion of course, but I think we should try to make the process to contribute code to the TC as light-weight as possible, to encourage people to contribute to our open repositories vs. just throw it up on their own Github account - as if they do that, then IPR and access is not as assured. Having to make a motion to create a new repository every time someone wants to contribute some new code, is a fairly heavyweight process in my opinion. It also means that only TC members can contribute any "new things", because the public can't trigger a vote on making a new repository - so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member). Jason, I'll raise the matter of requiring a motion/ballot with Staff. We probably want some kind of confirmation from the TC Chairs(s) -- indicating that there was consensus on the key elements of the request (name, Maintainers, choice of FOSS license, etc) Re: > a whole bunch of various code contributions from vendors, members and hopefully non-members alike That sounds great, and OASIS Open Repositories are intended to support that. It's a TC decision whether you want more or fewer repositories. It's a TC decision as to whether the repos are described as "generic" or having closely defined focus. I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" For the OASIS Open Repositories, once the repo is created, anyone from "the public" (non-TC member) can be a full participant, including Maintainer, per consensus. They can contribute "new things" in the same way as anyone can contribute new things to any GitHub public repository. Perhaps I misunderstand your concern.... I have assumed, maybe incorrectly, that your mention of a new repository (additional to those reported by Greg Back [1]) meant you want a new OASIS Open Repository ( https://www.oasis-open.org/resources/open-repositories ) - Robin [1] cti-stix2-json-schemas cti-pattern-validator cti-marking-prototype cti-stix-visualization cti-stix-validator cti-documentation cti-cybox3-json-schemas - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/28/2016 10:35:01 PM---Jason, The decision about creating something like "stix-tools" is (of course) a From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/28/2016 10:35 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > Jason, The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race. Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository. One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent) design that uses folders within a single repository. Using separate repos means less work (design work, workday-work) when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo. Just use one taxonomy of types/labels without namespace worries. And: you can five write privs to relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects... But as always: it's up to the TC, and I am no expert here. - Robin On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Hello all; IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement. It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets? -- Sent from my mobile device, please excuse any typos. Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories --- From: "Kirillov, Ivan A." < ikirillov@mitre.org > To: "Back, Greg" < gback@mitre.org >, cti@lists.oasis-open.org Date: Wed, Sep 28, 2016 2:09 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-) Regards, Ivan On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org on behalf of Back, Greg" < cti@lists.oasis-open.org on behalf of gback@mitre.org > wrote: >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS. > >- cti-stix2-json-schemas >- cti-pattern-validator >- cti-marking-prototype >- cti-stix-visualization >- cti-stix-validator > >There are two other repositories that exist, but do not (yet) have any content: > >- cti-documentation >- cti-cybox3-json-schemas > >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor License Agreement (CLA): https://www.oasis-open.org/resources/open-repositories/cla . This applies *even to TC members*. > >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions about the process, etc. > >You can find the repositories here: https://github.com/oasis-open > >Thanks, > >Greg Back >MITRE > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > -- -- -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783


  • 16.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-05-2016 14:54
    I'm not implying blanket disagreement with Mark's idea, but to answer your question > as a user, how do I quickly filter this list to only contain only CTI TC items (or any other TC)?  Go to:   https://github.com/oasis-open In the search box (upper left), "Filters" - "Find a repository":: a) type in: cti b) type in: dita c) type in: tosca That filter should work, and we designed the repository naming rules to exploit the GitHub org filter - Robin On Wed, Oct 5, 2016 at 9:46 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: The other aspect of this that should be considered by OASIS IMO, and why Mark's plan is very good - is that as these open repositories grow, it is going to quickly become a management headache under the current structure, because it lacks the ability to break things down by TC. Image our TC has 20 repos, another has 10, another has 15... quickly, when one goes to https://github.com/oasis-open/ , they will be confronted with a list of hundreds of repositories... as a user, how do I quickly filter this list to only contain only CTI TC items (or any other TC)? Whereas, if we use Mark's plan, all of the repos for a given TC are in one place, and it is easy as a user to find them on Github. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Mark Davidson ---10/05/2016 10:53:48 AM---Robin, My primary concern is that balloting seems slightly more heavyweight of a process than necess From: Mark Davidson < mdavidson@soltra.com > To: Robin Cover < robin@oasis-open.org > Cc: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >, Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Jason Keirstead/CanEast/IBM@IBMCA, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org > Date: 10/05/2016 10:53 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > Robin, My primary concern is that balloting seems slightly more heavyweight of a process than necessary for governing the GitHub Repos. To your main point, I do think there is a way to improve the process to a mutually agreeable end state. You raise some good questions, and I’d like to address them directly: > 1. Can you clarify that you make reference to GitHub repos that are used only by TC Members, governed by all OASIS policies (IPR, TC Process...) as opposed to "open" repositories that allow participation by anyone, via CLA, under open source licensing ? I am talking about GitHub repos that are governed by OASIS policies. I am under the impression that these repositories can be used by anyone. > 2. Can you explain why GitHub Project Pages will not work for the TCs? What features of Organization Pages are lacking in Project Pages [1]? There’s two reasons I’d like to consider one GitHub organization or the CTI TC (vs one GitHub org for all things OASIS) First - User, Project, and Organization pages differ in terms of the Hostname/URL that GitHub provides. Personally, I feel pretty strongly that our websites should have names that are short and easy to remember. In my opinion, e.g., https://oasis-open.github.io/ cti-documentation just will not stick with people the same way that https://stixproject.github.io sticks with people. There are other ways to achieve this – including a custom domain [1], but we should figure it out IMO. Second – The way people use GitHub, it (IMO) just makes more sense for related repos to be under a single GitHub organization and for unrelated repos to be located somewhere else. I’m interested in what other people think here (I’m just one opinon), but I’m strongly in favor of having one GitHub org for the CTI TC. > 3. Are you proposing that the repos you envision are NOT governed by OASIS rules? My apologies – I picked a bad example (repo deletion). My goal is a better process. In no way do I intend to circumvent or avoid the rules that we all agreed to support by joining OASIS. Thank you. -Mark [1] https://help.github.com/ articles/using-a-custom- domain-with-github-pages/ From: Robin Cover < robin@oasis-open.org > Date: Wednesday, October 5, 2016 at 9:04 AM To: Mark Davidson < mdavidson@soltra.com > Cc: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >, Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, Robin Cover < robin@oasis-open.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories Mark, I'll try to track with the conversation referenced below. We (OASIS) did consider several alternatives when designing the current plans for OASIS Open Repositories and (distinct from) GitHub Repos for TC work. Initially, two questions for you 1. Can you clarify that you make reference to GitHub repos that are used only by TC Members, governed by all OASIS policies (IPR, TC Process...) as opposed to "open" repositories that allow participation by anyone, via CLA, under open source licensing ? 2. Can you explain why GitHub Project Pages will not work for the TCs? What features of Organization Pages are lacking in Project Pages [1]? 3. Are you proposing that the repos you envision are NOT governed by OASIS rules? Foe example, you talk about repo deletion as a desirable feature ("t he operating rules can be superseded by a ballot on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted.." OASIS rules prohibit deletion of resources created by TC members [2] Comment: If you principal concern is about "ballots" (" A set of operating rules for managing repos that does NOT require a ballot"), then I think there is room within OASIS practice (and policy), perhaps with a few clarifications and updates, to allow most of what a TC wants to do -- without ballot. The matter of requiring a ballot for TC creation was raised earlier: under current OASIS rules, a "ballot" is not required for creation of an OASIS Open Repository or for the creation of a TC GitHub repo (repository for TC CHartered work). What's required is meeting minutes. We can clarify that further. That's all for now. Thanks, - Robin [1] https://help.github.com/ articles/user-organization- and-project-pages/#project- pages [2] http://docs.oasis-open.org/ specGuidelines/ndr/ namingDirectives.html# resourcePermanence Resource Permanence As part of the OASIS institutional commitment to transparency, openness, accountability, and public auditability, resources published in the OASIS Library, TC Document Repository, and other venues must not be deleted or otherwise altered. Resources may be revised, but all revisions are retained. With the exception of resources identified by "latest version" URI aliases, content instantiated as regular files and directories must not be over-written, replaced, renamed, or removed. TC Members are expected to follow this rule even in cases where a collaboration tool (by some means) might allow resource deletion or silent alteration. On Wed, Oct 5, 2016 at 7:30 AM, Mark Davidson < mdavidson@soltra.com > wrote: I realize this might go against the grain for some, but maybe we should talk about the organization of GitHub repos on the next working call. Personally, having one OASIS organization for _all_ GitHub repos is going to make tracking the work of any single TC more difficult. In addition, one OASIS organization prevents individual TCs from having *. github.io pages, which the STIX/TAXII group has made good use of in the past. I’d like it if we could consider a method that would provide the necessary governance AND make the management of GitHub repos a little less cumbersome. I don’t know if it’s feasible, but I’d be interested in exploring a structure that has the following properties: · A GitHub organization for the CTI TC (e.g., github.com/oasis-cti-tc/ ) · All CTI TC repos fall under the OASIS-CTI-TC GitHub Org · A set of operating rules for managing repos that does NOT require a ballot. Possible operating rules: o New repos require sponsorship by a co-chair and sign-off by the TC chair o Repo maintainer has some authority over who has which rights o Any part of the operating rules can be superseded by a ballot on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted) · Other considerations? Basically, my goal would be to free us up a bit in terms of repo management, while staying true to the intent of participating in OASIS. What do people think? Thank you. -Mark From: < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org > Date: Tuesday, October 4, 2016 at 7:02 PM To: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com > Cc: Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories Another resource on submodules "Working with submodules" (February 01, 2016) https://github.com/blog/2104- working-with-submodules -rcc On Tue, Oct 4, 2016 at 3:56 PM, Ted Bedwell (tebedwel) < tebedwel@cisco.com > wrote: For the other git neophytes out there: https://git-scm.com/book/en/ v2/Git-Tools-Submodules http://blogs.atlassian.com/ 2013/03/git-submodules- workflows-tips/ This seems like a viable approach. From: < cti@lists.oasis-open.org > on behalf of Terry MacDonald < terry.macdonald@cosive.com > Date: Tuesday, October 4, 2016 at 3:19 PM To: "Bret Jordan (CS)" < Bret_Jordan@symantec.com > Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories Couldn't we do a git repo containing submodules? Then each tool can have its own git repo, and it can be linked a submodules into the overall tools collection repo. This then makes it easy for everyone to get a copy of all three rows from one place, and yet we avoid the problems with many different people who only need access to parts of the git tree... Cheers Terry MacDonald Cosive On 4 Oct. 2016 9:09 am, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote: The problem with all of this is that it is not a collection of repos, but rather specific repos. Including multiple projects in a single repo is considered "bad form". Yes, you can do funky things with TAGS and you can even use different directories in the same repo. But that kind of break the git model. So instead of OASIS creating a oasis-open project with a bunch of arrant TC repos underneath, it seems like OASIS should setup a TC specific "projects". Then the TC can create as many repos on the project that it wants. Bret From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org > Sent: Thursday, September 29, 2016 8:28:43 AM To: Jason Keirstead Cc: Kirillov, Ivan A.; Back, Greg; OASIS CTI TC Discussion List; Robin Cover Subject: Re: [cti] Status of CTI OASIS Open Repositories On Thu, Sep 29, 2016 at 9:14 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: RE " I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" " It is basically tied back to the need, currently, to be a TC member and make a motion if you want to make a new repository OK, I understand. I'll raise the issue with Staff: can/should we support some means whereby a non-TC Member can easily make request for a new OASIS Open Repository where it's perceived that no existing Open Repository repository is suitable. , combined with these repositories being tied to very specific projects and not having a generic top-level repository. In the case at hand: the CTI TC can create an OASIS Open Repository described as "generic": that is your choice. I suppose you could also characterize some new OASIS Open Repository as "top-level" (notionally) if the TC members wanted to do that. Imagine a non-TC member has some brand new code they want to contribute, but it does not fall into any of these existing open repository categories, and we have no "generic" type of repository. They can not make a new repository, or even motion to make one, as they are not a TC member. They're stuck. The only way they could donate this code, would be to try to proxy through another TC member to get the repository created for them to commit it to. I strongly suspect that instead of that hassle they would just put it up on their own Github. Thanks for the clarification via examples. I'll certainly raise the issue with Staff. All such suggestions for improvement are welcome. Kindest regards and best wishes, - Robin - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/29/2016 09:28:30 AM---On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/29/2016 09:28 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I hear what you are saying and there are definitely pros and cons to having some more generic repositories - but I am trying to envision the near future where we will hopefully have a whole bunch of various code contributions from vendors, members and hopefully non-members alike. This is just my opinion of course, but I think we should try to make the process to contribute code to the TC as light-weight as possible, to encourage people to contribute to our open repositories vs. just throw it up on their own Github account - as if they do that, then IPR and access is not as assured. Having to make a motion to create a new repository every time someone wants to contribute some new code, is a fairly heavyweight process in my opinion. It also means that only TC members can contribute any "new things", because the public can't trigger a vote on making a new repository - so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member). Jason, I'll raise the matter of requiring a motion/ballot with Staff. We probably want some kind of confirmation from the TC Chairs(s) -- indicating that there was consensus on the key elements of the request (name, Maintainers, choice of FOSS license, etc) Re: > a whole bunch of various code contributions from vendors, members and hopefully non-members alike That sounds great, and OASIS Open Repositories are intended to support that. It's a TC decision whether you want more or fewer repositories. It's a TC decision as to whether the repos are described as "generic" or having closely defined focus. I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" For the OASIS Open Repositories, once the repo is created, anyone from "the public" (non-TC member) can be a full participant, including Maintainer, per consensus. They can contribute "new things" in the same way as anyone can contribute new things to any GitHub public repository. Perhaps I misunderstand your concern.... I have assumed, maybe incorrectly, that your mention of a new repository (additional to those reported by Greg Back [1]) meant you want a new OASIS Open Repository ( https://www.oasis-open.org/ resources/open-repositories ) - Robin [1] cti-stix2-json-schemas cti-pattern-validator cti-marking-prototype cti-stix-visualization cti-stix-validator cti-documentation cti-cybox3-json-schemas - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/28/2016 10:35:01 PM---Jason, The decision about creating something like "stix-tools" is (of course) a From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/28/2016 10:35 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > Jason, The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race. Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository. One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent) design that uses folders within a single repository. Using separate repos means less work (design work, workday-work) when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo. Just use one taxonomy of types/labels without namespace worries. And: you can five write privs to relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects... But as always: it's up to the TC, and I am no expert here. - Robin On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Hello all; IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement. It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets? -- Sent from my mobile device, please excuse any typos. Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories --- From: "Kirillov, Ivan A." < ikirillov@mitre.org > To: "Back, Greg" < gback@mitre.org >, cti@lists.oasis-open.org Date: Wed, Sep 28, 2016 2:09 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-) Regards, Ivan On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org on behalf of Back, Greg" < cti@lists.oasis-open.org on behalf of gback@mitre.org > wrote: >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS. > >- cti-stix2-json-schemas >- cti-pattern-validator >- cti-marking-prototype >- cti-stix-visualization >- cti-stix-validator > >There are two other repositories that exist, but do not (yet) have any content: > >- cti-documentation >- cti-cybox3-json-schemas > >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor License Agreement (CLA): https://www.oasis-open.org/ resources/open-repositories/ cla . This applies *even to TC members*. > >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions about the process, etc. > >You can find the repositories here: https://github.com/oasis-open > >Thanks, > >Greg Back >MITRE > >----------------------------- ------------------------------ ---------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/ apps/org/workgroup/portal/my_ workgroups.php > -- -- -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/ people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/ newsletterArchive.html Tel: +1 972-296-1783 -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783


  • 17.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-05-2016 15:02
    I guess what I mean is... if I am "average joe", I am probably going to type "STIX" in that filter, not "cti". - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---10/05/2016 11:55:15 AM---I'm not implying blanket disagreement with Mark's idea, but to answer your question From: Robin Cover <robin@oasis-open.org> To: Jason Keirstead/CanEast/IBM@IBMCA Cc: Mark Davidson <mdavidson@soltra.com>, "Ted Bedwell (tebedwel)" <tebedwel@cisco.com>, Terry MacDonald <terry.macdonald@cosive.com>, "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "Kirillov, Ivan A." <ikirillov@mitre.org>, "Back, Greg" <gback@mitre.org>, Robin Cover <robin@oasis-open.org> Date: 10/05/2016 11:55 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories I'm not implying blanket disagreement with Mark's idea, but to answer your question > as a user, how do I quickly filter this list to only contain only CTI TC items (or any other TC)?  Go to:   https://github.com/oasis-open In the search box (upper left), "Filters" - "Find a repository":: a) type in: cti b) type in: dita c) type in: tosca That filter should work, and we designed the repository naming rules to exploit the GitHub org filter - Robin On Wed, Oct 5, 2016 at 9:46 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: The other aspect of this that should be considered by OASIS IMO, and why Mark's plan is very good - is that as these open repositories grow, it is going to quickly become a management headache under the current structure, because it lacks the ability to break things down by TC. Image our TC has 20 repos, another has 10, another has 15... quickly, when one goes to https://github.com/oasis-open/ , they will be confronted with a list of hundreds of repositories... as a user, how do I quickly filter this list to only contain only CTI TC items (or any other TC)? Whereas, if we use Mark's plan, all of the repos for a given TC are in one place, and it is easy as a user to find them on Github. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Mark Davidson ---10/05/2016 10:53:48 AM---Robin, My primary concern is that balloting seems slightly more heavyweight of a process than necess From: Mark Davidson < mdavidson@soltra.com > To: Robin Cover < robin@oasis-open.org > Cc: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >, Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Jason Keirstead/CanEast/IBM@IBMCA, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org > Date: 10/05/2016 10:53 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > Robin, My primary concern is that balloting seems slightly more heavyweight of a process than necessary for governing the GitHub Repos. To your main point, I do think there is a way to improve the process to a mutually agreeable end state. You raise some good questions, and I’d like to address them directly: > 1. Can you clarify that you make reference to GitHub repos that are used only by TC Members, governed by all OASIS policies (IPR, TC Process...) as opposed to "open" repositories that allow participation by anyone, via CLA, under open source licensing ? I am talking about GitHub repos that are governed by OASIS policies. I am under the impression that these repositories can be used by anyone. > 2. Can you explain why GitHub Project Pages will not work for the TCs? What features of Organization Pages are lacking in Project Pages [1]? There’s two reasons I’d like to consider one GitHub organization or the CTI TC (vs one GitHub org for all things OASIS) First - User, Project, and Organization pages differ in terms of the Hostname/URL that GitHub provides. Personally, I feel pretty strongly that our websites should have names that are short and easy to remember. In my opinion, e.g., https://oasis-open.github.io/cti-documentation just will not stick with people the same way that https://stixproject.github.io sticks with people. There are other ways to achieve this – including a custom domain [1], but we should figure it out IMO. Second – The way people use GitHub, it (IMO) just makes more sense for related repos to be under a single GitHub organization and for unrelated repos to be located somewhere else. I’m interested in what other people think here (I’m just one opinon), but I’m strongly in favor of having one GitHub org for the CTI TC. > 3. Are you proposing that the repos you envision are NOT governed by OASIS rules? My apologies – I picked a bad example (repo deletion). My goal is a better process. In no way do I intend to circumvent or avoid the rules that we all agreed to support by joining OASIS. Thank you. -Mark [1] https://help.github.com/articles/using-a-custom-domain-with-github-pages/ From: Robin Cover < robin@oasis-open.org > Date: Wednesday, October 5, 2016 at 9:04 AM To: Mark Davidson < mdavidson@soltra.com > Cc: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >, Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, Robin Cover < robin@oasis-open.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories Mark, I'll try to track with the conversation referenced below. We (OASIS) did consider several alternatives when designing the current plans for OASIS Open Repositories and (distinct from) GitHub Repos for TC work. Initially, two questions for you 1. Can you clarify that you make reference to GitHub repos that are used only by TC Members, governed by all OASIS policies (IPR, TC Process...) as opposed to "open" repositories that allow participation by anyone, via CLA, under open source licensing ? 2. Can you explain why GitHub Project Pages will not work for the TCs? What features of Organization Pages are lacking in Project Pages [1]? 3. Are you proposing that the repos you envision are NOT governed by OASIS rules? Foe example, you talk about repo deletion as a desirable feature ("t he operating rules can be superseded by a ballot on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted.." OASIS rules prohibit deletion of resources created by TC members [2] Comment: If you principal concern is about "ballots" (" A set of operating rules for managing repos that does NOT require a ballot"), then I think there is room within OASIS practice (and policy), perhaps with a few clarifications and updates, to allow most of what a TC wants to do -- without ballot. The matter of requiring a ballot for TC creation was raised earlier: under current OASIS rules, a "ballot" is not required for creation of an OASIS Open Repository or for the creation of a TC GitHub repo (repository for TC CHartered work). What's required is meeting minutes. We can clarify that further. That's all for now. Thanks, - Robin [1] https://help.github.com/articles/user-organization-and-project-pages/#project-pages [2] http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#resourcePermanence Resource Permanence As part of the OASIS institutional commitment to transparency, openness, accountability, and public auditability, resources published in the OASIS Library, TC Document Repository, and other venues must not be deleted or otherwise altered. Resources may be revised, but all revisions are retained. With the exception of resources identified by "latest version" URI aliases, content instantiated as regular files and directories must not be over-written, replaced, renamed, or removed. TC Members are expected to follow this rule even in cases where a collaboration tool (by some means) might allow resource deletion or silent alteration. On Wed, Oct 5, 2016 at 7:30 AM, Mark Davidson < mdavidson@soltra.com > wrote: I realize this might go against the grain for some, but maybe we should talk about the organization of GitHub repos on the next working call. Personally, having one OASIS organization for _all_ GitHub repos is going to make tracking the work of any single TC more difficult. In addition, one OASIS organization prevents individual TCs from having *. github.io pages, which the STIX/TAXII group has made good use of in the past. I’d like it if we could consider a method that would provide the necessary governance AND make the management of GitHub repos a little less cumbersome. I don’t know if it’s feasible, but I’d be interested in exploring a structure that has the following properties: · A GitHub organization for the CTI TC (e.g., github.com/oasis-cti-tc/ ) · All CTI TC repos fall under the OASIS-CTI-TC GitHub Org · A set of operating rules for managing repos that does NOT require a ballot. Possible operating rules: o New repos require sponsorship by a co-chair and sign-off by the TC chair o Repo maintainer has some authority over who has which rights o Any part of the operating rules can be superseded by a ballot on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted) · Other considerations? Basically, my goal would be to free us up a bit in terms of repo management, while staying true to the intent of participating in OASIS. What do people think? Thank you. -Mark From: < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org > Date: Tuesday, October 4, 2016 at 7:02 PM To: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com > Cc: Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories Another resource on submodules "Working with submodules" (February 01, 2016) https://github.com/blog/2104-working-with-submodules -rcc On Tue, Oct 4, 2016 at 3:56 PM, Ted Bedwell (tebedwel) < tebedwel@cisco.com > wrote: For the other git neophytes out there: https://git-scm.com/book/en/v2/Git-Tools-Submodules http://blogs.atlassian.com/2013/03/git-submodules-workflows-tips/ This seems like a viable approach. From: < cti@lists.oasis-open.org > on behalf of Terry MacDonald < terry.macdonald@cosive.com > Date: Tuesday, October 4, 2016 at 3:19 PM To: "Bret Jordan (CS)" < Bret_Jordan@symantec.com > Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories Couldn't we do a git repo containing submodules? Then each tool can have its own git repo, and it can be linked a submodules into the overall tools collection repo. This then makes it easy for everyone to get a copy of all three rows from one place, and yet we avoid the problems with many different people who only need access to parts of the git tree... Cheers Terry MacDonald Cosive On 4 Oct. 2016 9:09 am, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote: The problem with all of this is that it is not a collection of repos, but rather specific repos. Including multiple projects in a single repo is considered "bad form". Yes, you can do funky things with TAGS and you can even use different directories in the same repo. But that kind of break the git model. So instead of OASIS creating a oasis-open project with a bunch of arrant TC repos underneath, it seems like OASIS should setup a TC specific "projects". Then the TC can create as many repos on the project that it wants. Bret From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org > Sent: Thursday, September 29, 2016 8:28:43 AM To: Jason Keirstead Cc: Kirillov, Ivan A.; Back, Greg; OASIS CTI TC Discussion List; Robin Cover Subject: Re: [cti] Status of CTI OASIS Open Repositories On Thu, Sep 29, 2016 at 9:14 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: RE " I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" " It is basically tied back to the need, currently, to be a TC member and make a motion if you want to make a new repository OK, I understand. I'll raise the issue with Staff: can/should we support some means whereby a non-TC Member can easily make request for a new OASIS Open Repository where it's perceived that no existing Open Repository repository is suitable. , combined with these repositories being tied to very specific projects and not having a generic top-level repository. In the case at hand: the CTI TC can create an OASIS Open Repository described as "generic": that is your choice. I suppose you could also characterize some new OASIS Open Repository as "top-level" (notionally) if the TC members wanted to do that. Imagine a non-TC member has some brand new code they want to contribute, but it does not fall into any of these existing open repository categories, and we have no "generic" type of repository. They can not make a new repository, or even motion to make one, as they are not a TC member. They're stuck. The only way they could donate this code, would be to try to proxy through another TC member to get the repository created for them to commit it to. I strongly suspect that instead of that hassle they would just put it up on their own Github. Thanks for the clarification via examples. I'll certainly raise the issue with Staff. All such suggestions for improvement are welcome. Kindest regards and best wishes, - Robin - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/29/2016 09:28:30 AM---On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/29/2016 09:28 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I hear what you are saying and there are definitely pros and cons to having some more generic repositories - but I am trying to envision the near future where we will hopefully have a whole bunch of various code contributions from vendors, members and hopefully non-members alike. This is just my opinion of course, but I think we should try to make the process to contribute code to the TC as light-weight as possible, to encourage people to contribute to our open repositories vs. just throw it up on their own Github account - as if they do that, then IPR and access is not as assured. Having to make a motion to create a new repository every time someone wants to contribute some new code, is a fairly heavyweight process in my opinion. It also means that only TC members can contribute any "new things", because the public can't trigger a vote on making a new repository - so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member). Jason, I'll raise the matter of requiring a motion/ballot with Staff. We probably want some kind of confirmation from the TC Chairs(s) -- indicating that there was consensus on the key elements of the request (name, Maintainers, choice of FOSS license, etc) Re: > a whole bunch of various code contributions from vendors, members and hopefully non-members alike That sounds great, and OASIS Open Repositories are intended to support that. It's a TC decision whether you want more or fewer repositories. It's a TC decision as to whether the repos are described as "generic" or having closely defined focus. I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" For the OASIS Open Repositories, once the repo is created, anyone from "the public" (non-TC member) can be a full participant, including Maintainer, per consensus. They can contribute "new things" in the same way as anyone can contribute new things to any GitHub public repository. Perhaps I misunderstand your concern.... I have assumed, maybe incorrectly, that your mention of a new repository (additional to those reported by Greg Back [1]) meant you want a new OASIS Open Repository ( https://www.oasis-open.org/resources/open-repositories ) - Robin [1] cti-stix2-json-schemas cti-pattern-validator cti-marking-prototype cti-stix-visualization cti-stix-validator cti-documentation cti-cybox3-json-schemas - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/28/2016 10:35:01 PM---Jason, The decision about creating something like "stix-tools" is (of course) a From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/28/2016 10:35 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > Jason, The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race. Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository. One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent) design that uses folders within a single repository. Using separate repos means less work (design work, workday-work) when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo. Just use one taxonomy of types/labels without namespace worries. And: you can five write privs to relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects... But as always: it's up to the TC, and I am no expert here. - Robin On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Hello all; IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement. It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets? -- Sent from my mobile device, please excuse any typos. Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories --- From: "Kirillov, Ivan A." < ikirillov@mitre.org > To: "Back, Greg" < gback@mitre.org >, cti@lists.oasis-open.org Date: Wed, Sep 28, 2016 2:09 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-) Regards, Ivan On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org on behalf of Back, Greg" < cti@lists.oasis-open.org on behalf of gback@mitre.org > wrote: >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS. > >- cti-stix2-json-schemas >- cti-pattern-validator >- cti-marking-prototype >- cti-stix-visualization >- cti-stix-validator > >There are two other repositories that exist, but do not (yet) have any content: > >- cti-documentation >- cti-cybox3-json-schemas > >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor License Agreement (CLA): https://www.oasis-open.org/resources/open-repositories/cla . This applies *even to TC members*. > >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions about the process, etc. > >You can find the repositories here: https://github.com/oasis-open > >Thanks, > >Greg Back >MITRE > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > -- -- -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783 -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783


  • 18.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-05-2016 15:11
    On Wed, Oct 5, 2016 at 10:01 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I guess what I mean is... if I am "average joe", I am probably going to type "STIX" in that filter, not "cti". I admit the filter is not perfect But: Type in: stix -rcc   - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---10/05/2016 11:55:15 AM---I'm not implying blanket disagreement with Mark's idea, but to answer your question From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: Mark Davidson < mdavidson@soltra.com >, "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >, Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, Robin Cover < robin@oasis-open.org > Date: 10/05/2016 11:55 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories I'm not implying blanket disagreement with Mark's idea, but to answer your question > as a user, how do I quickly filter this list to only contain only CTI TC items (or any other TC)?  Go to:   https://github.com/oasis-open In the search box (upper left), "Filters" - "Find a repository":: a) type in: cti b) type in: dita c) type in: tosca That filter should work, and we designed the repository naming rules to exploit the GitHub org filter - Robin On Wed, Oct 5, 2016 at 9:46 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: The other aspect of this that should be considered by OASIS IMO, and why Mark's plan is very good - is that as these open repositories grow, it is going to quickly become a management headache under the current structure, because it lacks the ability to break things down by TC. Image our TC has 20 repos, another has 10, another has 15... quickly, when one goes to https://github.com/oasis-open/ , they will be confronted with a list of hundreds of repositories... as a user, how do I quickly filter this list to only contain only CTI TC items (or any other TC)? Whereas, if we use Mark's plan, all of the repos for a given TC are in one place, and it is easy as a user to find them on Github. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Mark Davidson ---10/05/2016 10:53:48 AM---Robin, My primary concern is that balloting seems slightly more heavyweight of a process than necess From: Mark Davidson < mdavidson@soltra.com > To: Robin Cover < robin@oasis-open.org > Cc: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >, Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Jason Keirstead/CanEast/IBM@IBMCA, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org > Date: 10/05/2016 10:53 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > Robin, My primary concern is that balloting seems slightly more heavyweight of a process than necessary for governing the GitHub Repos. To your main point, I do think there is a way to improve the process to a mutually agreeable end state. You raise some good questions, and I’d like to address them directly: > 1. Can you clarify that you make reference to GitHub repos that are used only by TC Members, governed by all OASIS policies (IPR, TC Process...) as opposed to "open" repositories that allow participation by anyone, via CLA, under open source licensing ? I am talking about GitHub repos that are governed by OASIS policies. I am under the impression that these repositories can be used by anyone. > 2. Can you explain why GitHub Project Pages will not work for the TCs? What features of Organization Pages are lacking in Project Pages [1]? There’s two reasons I’d like to consider one GitHub organization or the CTI TC (vs one GitHub org for all things OASIS) First - User, Project, and Organization pages differ in terms of the Hostname/URL that GitHub provides. Personally, I feel pretty strongly that our websites should have names that are short and easy to remember. In my opinion, e.g., https://oasis-open.github.io/c ti-documentation just will not stick with people the same way that https://stixproject.github.io sticks with people. There are other ways to achieve this – including a custom domain [1], but we should figure it out IMO. Second – The way people use GitHub, it (IMO) just makes more sense for related repos to be under a single GitHub organization and for unrelated repos to be located somewhere else. I’m interested in what other people think here (I’m just one opinon), but I’m strongly in favor of having one GitHub org for the CTI TC. > 3. Are you proposing that the repos you envision are NOT governed by OASIS rules? My apologies – I picked a bad example (repo deletion). My goal is a better process. In no way do I intend to circumvent or avoid the rules that we all agreed to support by joining OASIS. Thank you. -Mark [1] https://help.github.com/articl es/using-a-custom-domain-with- github-pages/ From: Robin Cover < robin@oasis-open.org > Date: Wednesday, October 5, 2016 at 9:04 AM To: Mark Davidson < mdavidson@soltra.com > Cc: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >, Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, Robin Cover < robin@oasis-open.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories Mark, I'll try to track with the conversation referenced below. We (OASIS) did consider several alternatives when designing the current plans for OASIS Open Repositories and (distinct from) GitHub Repos for TC work. Initially, two questions for you 1. Can you clarify that you make reference to GitHub repos that are used only by TC Members, governed by all OASIS policies (IPR, TC Process...) as opposed to "open" repositories that allow participation by anyone, via CLA, under open source licensing ? 2. Can you explain why GitHub Project Pages will not work for the TCs? What features of Organization Pages are lacking in Project Pages [1]? 3. Are you proposing that the repos you envision are NOT governed by OASIS rules? Foe example, you talk about repo deletion as a desirable feature ("t he operating rules can be superseded by a ballot on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted.." OASIS rules prohibit deletion of resources created by TC members [2] Comment: If you principal concern is about "ballots" (" A set of operating rules for managing repos that does NOT require a ballot"), then I think there is room within OASIS practice (and policy), perhaps with a few clarifications and updates, to allow most of what a TC wants to do -- without ballot. The matter of requiring a ballot for TC creation was raised earlier: under current OASIS rules, a "ballot" is not required for creation of an OASIS Open Repository or for the creation of a TC GitHub repo (repository for TC CHartered work). What's required is meeting minutes. We can clarify that further. That's all for now. Thanks, - Robin [1] https://help.github.com/articl es/user-organization-and- project-pages/#project-pages [2] http://docs.oasis-open.org/spe cGuidelines/ndr/namingDirectiv es.html#resourcePermanence Resource Permanence As part of the OASIS institutional commitment to transparency, openness, accountability, and public auditability, resources published in the OASIS Library, TC Document Repository, and other venues must not be deleted or otherwise altered. Resources may be revised, but all revisions are retained. With the exception of resources identified by "latest version" URI aliases, content instantiated as regular files and directories must not be over-written, replaced, renamed, or removed. TC Members are expected to follow this rule even in cases where a collaboration tool (by some means) might allow resource deletion or silent alteration. On Wed, Oct 5, 2016 at 7:30 AM, Mark Davidson < mdavidson@soltra.com > wrote: I realize this might go against the grain for some, but maybe we should talk about the organization of GitHub repos on the next working call. Personally, having one OASIS organization for _all_ GitHub repos is going to make tracking the work of any single TC more difficult. In addition, one OASIS organization prevents individual TCs from having *. github.io pages, which the STIX/TAXII group has made good use of in the past. I’d like it if we could consider a method that would provide the necessary governance AND make the management of GitHub repos a little less cumbersome. I don’t know if it’s feasible, but I’d be interested in exploring a structure that has the following properties: · A GitHub organization for the CTI TC (e.g., github.com/oasis-cti-tc/ ) · All CTI TC repos fall under the OASIS-CTI-TC GitHub Org · A set of operating rules for managing repos that does NOT require a ballot. Possible operating rules: o New repos require sponsorship by a co-chair and sign-off by the TC chair o Repo maintainer has some authority over who has which rights o Any part of the operating rules can be superseded by a ballot on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted) · Other considerations? Basically, my goal would be to free us up a bit in terms of repo management, while staying true to the intent of participating in OASIS. What do people think? Thank you. -Mark From: < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org > Date: Tuesday, October 4, 2016 at 7:02 PM To: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com > Cc: Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories Another resource on submodules "Working with submodules" (February 01, 2016) https://github.com/blog/2104-w orking-with-submodules -rcc On Tue, Oct 4, 2016 at 3:56 PM, Ted Bedwell (tebedwel) < tebedwel@cisco.com > wrote: For the other git neophytes out there: https://git-scm.com/book/en/v2 /Git-Tools-Submodules http://blogs.atlassian.com/201 3/03/git-submodules-workflows- tips/ This seems like a viable approach. From: < cti@lists.oasis-open.org > on behalf of Terry MacDonald < terry.macdonald@cosive.com > Date: Tuesday, October 4, 2016 at 3:19 PM To: "Bret Jordan (CS)" < Bret_Jordan@symantec.com > Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories Couldn't we do a git repo containing submodules? Then each tool can have its own git repo, and it can be linked a submodules into the overall tools collection repo. This then makes it easy for everyone to get a copy of all three rows from one place, and yet we avoid the problems with many different people who only need access to parts of the git tree... Cheers Terry MacDonald Cosive On 4 Oct. 2016 9:09 am, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote: The problem with all of this is that it is not a collection of repos, but rather specific repos. Including multiple projects in a single repo is considered "bad form". Yes, you can do funky things with TAGS and you can even use different directories in the same repo. But that kind of break the git model. So instead of OASIS creating a oasis-open project with a bunch of arrant TC repos underneath, it seems like OASIS should setup a TC specific "projects". Then the TC can create as many repos on the project that it wants. Bret From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org > Sent: Thursday, September 29, 2016 8:28:43 AM To: Jason Keirstead Cc: Kirillov, Ivan A.; Back, Greg; OASIS CTI TC Discussion List; Robin Cover Subject: Re: [cti] Status of CTI OASIS Open Repositories On Thu, Sep 29, 2016 at 9:14 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: RE " I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" " It is basically tied back to the need, currently, to be a TC member and make a motion if you want to make a new repository OK, I understand. I'll raise the issue with Staff: can/should we support some means whereby a non-TC Member can easily make request for a new OASIS Open Repository where it's perceived that no existing Open Repository repository is suitable. , combined with these repositories being tied to very specific projects and not having a generic top-level repository. In the case at hand: the CTI TC can create an OASIS Open Repository described as "generic": that is your choice. I suppose you could also characterize some new OASIS Open Repository as "top-level" (notionally) if the TC members wanted to do that. Imagine a non-TC member has some brand new code they want to contribute, but it does not fall into any of these existing open repository categories, and we have no "generic" type of repository. They can not make a new repository, or even motion to make one, as they are not a TC member. They're stuck. The only way they could donate this code, would be to try to proxy through another TC member to get the repository created for them to commit it to. I strongly suspect that instead of that hassle they would just put it up on their own Github. Thanks for the clarification via examples. I'll certainly raise the issue with Staff. All such suggestions for improvement are welcome. Kindest regards and best wishes, - Robin - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/29/2016 09:28:30 AM---On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/29/2016 09:28 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I hear what you are saying and there are definitely pros and cons to having some more generic repositories - but I am trying to envision the near future where we will hopefully have a whole bunch of various code contributions from vendors, members and hopefully non-members alike. This is just my opinion of course, but I think we should try to make the process to contribute code to the TC as light-weight as possible, to encourage people to contribute to our open repositories vs. just throw it up on their own Github account - as if they do that, then IPR and access is not as assured. Having to make a motion to create a new repository every time someone wants to contribute some new code, is a fairly heavyweight process in my opinion. It also means that only TC members can contribute any "new things", because the public can't trigger a vote on making a new repository - so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member). Jason, I'll raise the matter of requiring a motion/ballot with Staff. We probably want some kind of confirmation from the TC Chairs(s) -- indicating that there was consensus on the key elements of the request (name, Maintainers, choice of FOSS license, etc) Re: > a whole bunch of various code contributions from vendors, members and hopefully non-members alike That sounds great, and OASIS Open Repositories are intended to support that. It's a TC decision whether you want more or fewer repositories. It's a TC decision as to whether the repos are described as "generic" or having closely defined focus. I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" For the OASIS Open Repositories, once the repo is created, anyone from "the public" (non-TC member) can be a full participant, including Maintainer, per consensus. They can contribute "new things" in the same way as anyone can contribute new things to any GitHub public repository. Perhaps I misunderstand your concern.... I have assumed, maybe incorrectly, that your mention of a new repository (additional to those reported by Greg Back [1]) meant you want a new OASIS Open Repository ( https://www.oasis-open.org/res ources/open-repositories ) - Robin [1] cti-stix2-json-schemas cti-pattern-validator cti-marking-prototype cti-stix-visualization cti-stix-validator cti-documentation cti-cybox3-json-schemas - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/28/2016 10:35:01 PM---Jason, The decision about creating something like "stix-tools" is (of course) a From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/28/2016 10:35 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > Jason, The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race. Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository. One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent) design that uses folders within a single repository. Using separate repos means less work (design work, workday-work) when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo. Just use one taxonomy of types/labels without namespace worries. And: you can five write privs to relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects... But as always: it's up to the TC, and I am no expert here. - Robin On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Hello all; IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement. It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets? -- Sent from my mobile device, please excuse any typos. Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories --- From: "Kirillov, Ivan A." < ikirillov@mitre.org > To: "Back, Greg" < gback@mitre.org >, cti@lists.oasis-open.org Date: Wed, Sep 28, 2016 2:09 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-) Regards, Ivan On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org on behalf of Back, Greg" < cti@lists.oasis-open.org on behalf of gback@mitre.org > wrote: >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS. > >- cti-stix2-json-schemas >- cti-pattern-validator >- cti-marking-prototype >- cti-stix-visualization >- cti-stix-validator > >There are two other repositories that exist, but do not (yet) have any content: > >- cti-documentation >- cti-cybox3-json-schemas > >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor License Agreement (CLA): https://www.oasis-open.org/res ources/open-repositories/cla . This applies *even to TC members*. > >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions about the process, etc. > >You can find the repositories here: https://github.com/oasis-open > >Thanks, > >Greg Back >MITRE > >----------------------------- ------------------------------ ---------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/ap ps/org/workgroup/portal/my_wor kgroups.php > -- -- -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/peop le/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/news letterArchive.html Tel: +1 972-296-1783 -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/peop le/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/news letterArchive.html Tel: +1 972-296-1783 -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/ people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/ newsletterArchive.html Tel: +1 972-296-1783


  • 19.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-05-2016 15:40




    I guess at a high level, it boils down to: If the OASIS CTI TC were to, by consensus, desire a GitHub organization for itself, would that be possible? If that’s possible, I’m happy to make
    a motion or do whatever is the best way to establish whether we have consensus.
     
    Thank you.
    -Mark
     

    From:
    Robin Cover <robin@oasis-open.org>
    Date: Wednesday, October 5, 2016 at 11:11 AM
    To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
    Cc: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "Back, Greg" <gback@mitre.org>, "Kirillov, Ivan A." <ikirillov@mitre.org>, Mark Davidson <mdavidson@soltra.com>, "Ted Bedwell (tebedwel)" <tebedwel@cisco.com>,
    Terry MacDonald <terry.macdonald@cosive.com>, Robin Cover <robin@oasis-open.org>
    Subject: Re: [cti] Status of CTI OASIS Open Repositories


     




    On Wed, Oct 5, 2016 at 10:01 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:


    I guess what I mean is... if I am "average joe", I am probably going to type "STIX" in that filter, not "cti".



     


    I admit the filter is not perfect


     


    But:


     


    Type in: stix


     


    -rcc


     




    -
    Jason Keirstead
    STSM, Product Architect, Security Intelligence, IBM Security Systems
    www.ibm.com/security
    www.securityintelligence.com

    Without data, all you are is just another person with an opinion - Unknown


    Robin Cover ---10/05/2016 11:55:15 AM---I'm not implying
    blanket disagreement with Mark's idea, but to answer your question

    From: Robin Cover < robin@oasis-open.org >
    To: Jason Keirstead/CanEast/IBM@IBMCA
    Cc: Mark Davidson < mdavidson@soltra.com >, "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >,
    Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org "
    < cti@lists.oasis-open.org >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >,
    Robin Cover < robin@oasis-open.org >
    Date: 10/05/2016 11:55 AM
    Subject: Re: [cti] Status of CTI OASIS Open Repositories






    I'm not implying blanket disagreement with Mark's idea, but to answer your question

    > as a user, how do I quickly filter this list to only contain only CTI TC items (or any other TC)? 

    Go to:   https://github.com/oasis-open

    In the search box (upper left), "Filters" - "Find a repository"::

    a) type in: cti
    b) type in: dita
    c) type in: tosca

    That filter should work, and we designed the repository naming rules to exploit the GitHub org filter

    - Robin

    On Wed, Oct 5, 2016 at 9:46 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:

    The other aspect of this that should be considered by OASIS IMO, and why Mark's plan is very good - is that as these open repositories grow, it is going to quickly become a management
    headache under the current structure, because it lacks the ability to break things down by TC.

    Image our TC has 20 repos, another has 10, another has 15... quickly, when one goes to
    https://github.com/oasis-open/ , they will be confronted with a list of hundreds of repositories... as a user, how do I quickly
    filter this list to only contain only CTI TC items (or any other TC)?

    Whereas, if we use Mark's plan, all of the repos for a given TC are in one place, and it is easy as a user to find them on Github.

    -
    Jason Keirstead
    STSM, Product Architect, Security Intelligence, IBM Security Systems
    www.ibm.com/security
    www.securityintelligence.com

    Without data, all you are is just another person with an opinion - Unknown


    Mark Davidson ---10/05/2016
    10:53:48 AM---Robin, My primary concern is that balloting seems slightly more heavyweight of a process than necess

    From: Mark Davidson < mdavidson@soltra.com >
    To: Robin Cover < robin@oasis-open.org >
    Cc: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >, Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >,
    " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Jason Keirstead/CanEast/IBM@IBMCA, "Kirillov, Ivan A." < ikirillov@mitre.org >,
    "Back, Greg" < gback@mitre.org >
    Date: 10/05/2016 10:53 AM
    Subject: Re: [cti] Status of CTI OASIS Open Repositories
    Sent by: < cti@lists.oasis-open.org >






    Robin,

    My primary concern is that balloting seems slightly more heavyweight of a process than necessary for governing the GitHub Repos. To your main point, I do think there is a way to improve the process to a mutually agreeable end state.

    You raise some good questions, and I’d like to address them directly:

    > 1. Can you clarify that you make reference to GitHub repos that are used only by TC Members, governed by all OASIS policies (IPR, TC Process...) as opposed to "open" repositories that allow participation by anyone, via CLA, under open source licensing ?

    I am talking about GitHub repos that are governed by OASIS policies. I am under the impression that these repositories can be used by anyone.

    > 2. Can you explain why GitHub Project Pages will not work for the TCs? What features of Organization Pages are lacking in Project Pages [1]?

    There’s two reasons I’d like to consider one GitHub organization or the CTI TC (vs one GitHub org for all things OASIS)

    First - User, Project, and Organization pages differ in terms of the Hostname/URL that GitHub provides. Personally, I feel pretty strongly that our websites should have names that are short and easy to remember. In my opinion, e.g.,
    https://oasis-open.github.io/cti-documentation just will not stick
    with people the same way that https://stixproject.github.io sticks with people.
    There are other ways to achieve this – including a custom domain [1], but we should figure it out IMO.

    Second – The way people use GitHub, it (IMO) just makes more sense for related repos to be under a single GitHub organization and for unrelated repos to be located somewhere else. I’m interested in what other people think here (I’m just one opinon), but I’m
    strongly in favor of having one GitHub org for the CTI TC.

    > 3. Are you proposing that the repos you envision are NOT governed by OASIS rules?

    My apologies – I picked a bad example (repo deletion). My goal is a better process. In no way do I intend to circumvent or avoid the rules that we all agreed to support by joining OASIS.

    Thank you.
    -Mark

    [1] https://help.github.com/articles/using-a-custom-domain-with-github-pages/

    From: Robin Cover < robin@oasis-open.org >
    Date: Wednesday, October 5, 2016 at 9:04 AM
    To: Mark Davidson < mdavidson@soltra.com >
    Cc: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >, Terry MacDonald < terry.macdonald@cosive.com >,
    "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org "
    < cti@lists.oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >,
    "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >,
    Robin Cover < robin@oasis-open.org >
    Subject: Re: [cti] Status of CTI OASIS Open Repositories

    Mark,

    I'll try to track with the conversation referenced below. We (OASIS) did consider several alternatives when designing the current plans for OASIS Open Repositories and (distinct from) GitHub Repos for TC work.

    Initially, two questions for you

    1. Can you clarify that you make reference to GitHub repos that are used only by TC Members, governed by all OASIS policies (IPR, TC Process...) as opposed to "open" repositories that allow participation by anyone, via CLA, under open source licensing ?

    2. Can you explain why GitHub Project Pages will not work for the TCs? What features of Organization Pages are lacking in Project Pages [1]?

    3. Are you proposing that the repos you envision are NOT governed by OASIS rules? Foe example, you talk about repo deletion as a desirable feature ("t he operating rules can be superseded by a ballot
    on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted.." OASIS rules prohibit deletion of resources created by TC members [2]

    Comment:

    If you principal concern is about "ballots" (" A set of operating rules for managing repos that does NOT require a ballot"), then I think there is room within OASIS practice (and policy), perhaps with
    a few clarifications and updates, to allow most of what a TC wants to do -- without ballot. The matter of requiring a ballot for TC creation was raised earlier: under current OASIS rules, a "ballot" is not required for creation of an OASIS Open Repository
    or for the creation of a TC GitHub repo (repository for TC CHartered work). What's required is meeting minutes. We can clarify that further.

    That's all for now.

    Thanks,

    - Robin

    [1] https://help.github.com/articles/user-organization-and-project-pages/#project-pages


    [2] http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#resourcePermanence

    Resource Permanence
    As part of the OASIS institutional commitment to transparency, openness, accountability, and public auditability, resources published in the OASIS Library, TC Document Repository, and other venues must not be deleted or otherwise altered. Resources may be revised,
    but all revisions are retained. With the exception of resources identified by "latest version" URI aliases, content instantiated as regular files and directories must not be over-written, replaced, renamed, or removed. TC Members are expected to follow this
    rule even in cases where a collaboration tool (by some means) might allow resource deletion or silent alteration.


    On Wed, Oct 5, 2016 at 7:30 AM, Mark Davidson < mdavidson@soltra.com > wrote:
    I realize this might go against the grain for some, but maybe we should talk about the organization of GitHub repos on the next working call. Personally, having one OASIS organization for _all_ GitHub repos is going to make tracking the work of any single TC
    more difficult. In addition, one OASIS organization prevents individual TCs from having *. github.io
    pages, which the STIX/TAXII group has made good use of in the past. I’d like it if we could consider a method that would provide the necessary governance AND make the management of GitHub repos a little less cumbersome.

    I don’t know if it’s feasible, but I’d be interested in exploring a structure that has the following properties:

    ·
    A GitHub organization for the CTI TC (e.g.,
    github.com/oasis-cti-tc/ )
    ·
    All CTI TC repos fall under the OASIS-CTI-TC GitHub Org
    ·
    A set of operating rules for managing repos that does NOT require a ballot. Possible operating rules:
    o
    New repos require sponsorship by a co-chair and sign-off by the TC chair

    o
    Repo maintainer has some authority over who has which rights
    o
    Any part of the operating rules can be superseded by a ballot on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted)
    ·
    Other considerations?

    Basically, my goal would be to free us up a bit in terms of repo management, while staying true to the intent of participating in OASIS. What do people think?

    Thank you.
    -Mark

    From: < cti@lists.oasis-open.org >
    on behalf of Robin Cover < robin@oasis-open.org >
    Date: Tuesday, October 4, 2016 at 7:02 PM
    To: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >
    Cc: Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >,
    " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >,
    Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >,
    "Back, Greg" < gback@mitre.org >
    Subject: Re: [cti] Status of CTI OASIS Open Repositories

    Another resource on submodules

    "Working with submodules" (February 01, 2016)
    https://github.com/blog/2104-working-with-submodules

    -rcc

    On Tue, Oct 4, 2016 at 3:56 PM, Ted Bedwell (tebedwel) < tebedwel@cisco.com > wrote:

    For the other git neophytes out there:
    https://git-scm.com/book/en/v2/Git-Tools-Submodules
    http://blogs.atlassian.com/2013/03/git-submodules-workflows-tips/

    This seems like a viable approach.

    From: < cti@lists.oasis-open.org >
    on behalf of Terry MacDonald < terry.macdonald@cosive.com >
    Date: Tuesday, October 4, 2016 at 3:19 PM
    To: "Bret Jordan (CS)" < Bret_Jordan@symantec.com >
    Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >,
    Robin Cover < robin@oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >,
    "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >
    Subject: Re: [cti] Status of CTI OASIS Open Repositories
    Couldn't we do a git repo containing submodules? Then each tool can have its own git repo, and it can be linked a submodules into the overall tools collection repo.

    This then makes it easy for everyone to get a copy of all three rows from one place, and yet we avoid the problems with many different people who only need access to parts of the git tree...
    Cheers
    Terry MacDonald
    Cosive

    On 4 Oct. 2016 9:09 am, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote:
    The problem with all of this is that it is not a collection of repos, but rather specific repos. Including multiple projects in a single repo is considered "bad form". Yes, you can do funky things with TAGS and you can even use different directories in the
    same repo. But that kind of break the git model. So instead of OASIS creating a oasis-open project with a bunch of arrant TC repos underneath, it seems like OASIS should setup a TC specific "projects". Then the TC can create as many repos on the project that
    it wants.
    Bret
     



    From:
    cti@lists.oasis-open.org < cti@lists.oasis-open.org >
    on behalf of Robin Cover < robin@oasis-open.org >
    Sent: Thursday, September 29, 2016 8:28:43 AM
    To: Jason Keirstead
    Cc: Kirillov, Ivan A.; Back, Greg; OASIS CTI TC Discussion List; Robin Cover
    Subject: Re: [cti] Status of CTI OASIS Open Repositories


    On Thu, Sep 29, 2016 at 9:14 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:
    RE " I don't quite understand your meaning here:


    "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" "

    It is basically tied back to the need, currently, to be a TC member and make a motion if you want to make a new repository
    OK, I understand. I'll raise the issue with Staff: can/should we support some means whereby a non-TC Member can easily make request for a new OASIS Open Repository where it's perceived that no existing Open Repository repository is suitable.
    , combined with these repositories being tied to very specific projects and not having a generic top-level repository.
    In the case at hand: the CTI TC can create an OASIS Open Repository described as "generic": that is your choice. I suppose you could also characterize some new OASIS Open Repository as "top-level" (notionally) if the TC members wanted to do that.


    Imagine a non-TC member has some brand new code they want to contribute, but it does not fall into any of these existing open repository categories, and we have no "generic" type of repository. They can not make a new repository, or even motion to make one,
    as they are not a TC member. They're stuck. The only way they could donate this code, would be to try to proxy through another TC member to get the repository created for them to commit it to. I strongly suspect that instead of that hassle they would just
    put it up on their own Github.

    Thanks for the clarification via examples. I'll certainly raise the issue with Staff. All such suggestions for improvement are welcome.

    Kindest regards and best wishes,

    - Robin



    -
    Jason Keirstead
    STSM, Product Architect, Security Intelligence, IBM Security Systems
    www.ibm.com/security
    www.securityintelligence.com

    Without data, all you are is just another person with an opinion - Unknown


    Robin Cover ---09/29/2016 09:28:30
    AM---On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:

    From: Robin Cover < robin@oasis-open.org >
    To: Jason Keirstead/CanEast/IBM@IBMCA
    Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >,
    OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org >
    Date: 09/29/2016 09:28 AM
    Subject: Re: [cti] Status of CTI OASIS Open Repositories
    Sent by: < cti@lists.oasis-open.org >







    On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:

    I hear what you are saying and there are definitely pros and cons to having some more generic repositories - but I am trying to envision the near future where we will hopefully have
    a whole bunch of various code contributions from vendors, members and hopefully non-members alike. This is just my opinion of course, but I think we should try to make the process to contribute code to the TC as light-weight as possible, to encourage people
    to contribute to our open repositories vs. just throw it up on their own Github account - as if they do that, then IPR and access is not as assured. Having to make a motion to create a new repository every time someone wants to contribute some new code, is
    a fairly heavyweight process in my opinion. It also means that only TC members can contribute any "new things", because the public can't trigger a vote on making a new repository - so the public is basically only able to contribute to things that already exist,
    not contribute anything new (unless they proxy through a member).

    Jason, I'll raise the matter of requiring a motion/ballot with Staff. We probably want some kind of confirmation from the TC Chairs(s) -- indicating that there was consensus on the key elements of the request (name, Maintainers, choice of FOSS license, etc)

    Re:
    > a whole bunch of various code contributions from vendors, members and hopefully non-members alike

    That sounds great, and OASIS Open Repositories are intended to support that. It's a TC decision whether you want more or fewer repositories. It's a TC decision as to whether the repos are described as "generic" or having closely defined focus.

    I don't quite understand your meaning here:

    "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)"

    For the OASIS Open Repositories, once the repo is created, anyone from "the public" (non-TC member) can be a full participant, including Maintainer, per consensus. They can contribute "new things" in the same way as anyone can contribute new things to any GitHub
    public repository. Perhaps I misunderstand your concern....

    I have assumed, maybe incorrectly, that your mention of a new repository (additional to those reported by Greg Back [1]) meant you want a new OASIS Open Repository (
    https://www.oasis-open.org/resources/open-repositories )

    - Robin


    [1]

    cti-stix2-json-schemas
    cti-pattern-validator
    cti-marking-prototype
    cti-stix-visualization
    cti-stix-validator
    cti-documentation
    cti-cybox3-json-schemas

    -
    Jason Keirstead
    STSM, Product Architect, Security Intelligence, IBM Security Systems
    www.ibm.com/security
    www.securityintelligence.com

    Without data, all you are is just another person with an opinion - Unknown


    Robin Cover ---09/28/2016 10:35:01
    PM---Jason, The decision about creating something like "stix-tools" is (of course) a

    From: Robin Cover < robin@oasis-open.org >
    To: Jason Keirstead/CanEast/IBM@IBMCA
    Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >,
    OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org >
    Date: 09/28/2016 10:35 PM
    Subject: Re: [cti] Status of CTI OASIS Open Repositories
    Sent by: < cti@lists.oasis-open.org >







    Jason,

    The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race.

    Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository.

    One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent) design that uses folders within a single repository. Using separate repos means less work (design work, workday-work)
    when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo. Just use one taxonomy of types/labels without namespace worries. And: you can five write privs to
    relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects...

    But as always: it's up to the TC, and I am no expert here.

    - Robin

    On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:

    Hello all;

    IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement.

    It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets?

    --
    Sent from my mobile device, please excuse any typos.

    Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories ---





    From:


    "Kirillov, Ivan A." < ikirillov@mitre.org >




    To:


    "Back, Greg" < gback@mitre.org >,
    cti@lists.oasis-open.org




    Date:


    Wed, Sep 28, 2016 2:09 PM




    Subject:


    Re: [cti] Status of CTI OASIS Open Repositories









    Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-)

    Regards,
    Ivan

    On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org on behalf of Back,
    Greg" < cti@lists.oasis-open.org on behalf of
    gback@mitre.org > wrote:

    >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS.

    >
    >- cti-stix2-json-schemas
    >- cti-pattern-validator
    >- cti-marking-prototype
    >- cti-stix-visualization
    >- cti-stix-validator
    >
    >There are two other repositories that exist, but do not (yet) have any content:
    >
    >- cti-documentation
    >- cti-cybox3-json-schemas
    >
    >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor
    License Agreement (CLA): https://www.oasis-open.org/resources/open-repositories/cla
    . This applies *even to TC members*.
    >
    >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions
    about the process, etc.
    >
    >You can find the repositories here: https://github.com/oasis-open

    >
    >Thanks,
    >
    >Greg Back
    >MITRE
    >
    >---------------------------------------------------------------------
    >To unsubscribe from this mail list, you must leave the OASIS TC that
    >generates this mail. Follow this link to all your TCs in OASIS at:
    > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

    >



    --




    --




    --
    Robin Cover
    OASIS, Director of Information Services
    Editor, Cover Pages and XML Daily Newslink
    Email: robin@oasis-open.org
    Staff bio: http://www.oasis-open.org/peo p le/staff/robin-cover
    Cover Pages: http://xml.coverpages.org/
    Newsletter: http://xml.coverpages.org/new s letterArchive.html
    Tel: +1 972-296-1783




    --

    Robin Cover
    OASIS, Director of Information Services
    Editor, Cover Pages and XML Daily Newslink
    Email: robin@oasis-open.org
    Staff bio: http://www.oasis-open.org/peo p le/staff/robin-cover
    Cover Pages: http://xml.coverpages.org/
    Newsletter: http://xml.coverpages.org/new s letterArchive.html
    Tel:
    +1 972-296-1783









     

    --

    Robin Cover
    OASIS, Director of Information Services
    Editor, Cover Pages and XML Daily Newslink
    Email: robin@oasis-open.org
    Staff bio:
    http://www.oasis-open.org/people/staff/robin-cover
    Cover Pages: http://xml.coverpages.org/
    Newsletter:
    http://xml.coverpages.org/newsletterArchive.html
    Tel: +1 972-296-1783









  • 20.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-05-2016 15:49
    Mark asked: > ....  would that be possible? If that’s possible Mark, I think you are asking whether OASIS, as owner of the proposed Organization, would modify current policy/practice to create and support a new GitHub Organization for the CTI TC.  Is that correct? I am happy to bring this question to relevant OASIS Staff -- soon, or later -- if that is the question you are asking. I was rather expecting some additional feedback --  from others on the CTI TC who have significant experience with GitHub. Cheers, - Robin On Wed, Oct 5, 2016 at 10:40 AM, Mark Davidson < mdavidson@soltra.com > wrote: I guess at a high level, it boils down to: If the OASIS CTI TC were to, by consensus, desire a GitHub organization for itself, would that be possible? If that’s possible, I’m happy to make a motion or do whatever is the best way to establish whether we have consensus.   Thank you. -Mark   From: Robin Cover < robin@oasis-open.org > Date: Wednesday, October 5, 2016 at 11:11 AM To: Jason Keirstead < Jason.Keirstead@ca.ibm.com > Cc: "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, "Back, Greg" < gback@mitre.org >, "Kirillov, Ivan A." < ikirillov@mitre.org >, Mark Davidson < mdavidson@soltra.com >, "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >, Terry MacDonald < terry.macdonald@cosive.com >, Robin Cover < robin@oasis-open.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories   On Wed, Oct 5, 2016 at 10:01 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I guess what I mean is... if I am "average joe", I am probably going to type "STIX" in that filter, not "cti".   I admit the filter is not perfect   But:   Type in: stix   -rcc   - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---10/05/2016 11:55:15 AM---I'm not implying blanket disagreement with Mark's idea, but to answer your question From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: Mark Davidson < mdavidson@soltra.com >, "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >, Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, Robin Cover < robin@oasis-open.org > Date: 10/05/2016 11:55 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories I'm not implying blanket disagreement with Mark's idea, but to answer your question > as a user, how do I quickly filter this list to only contain only CTI TC items (or any other TC)?  Go to:   https://github.com/oasis-open In the search box (upper left), "Filters" - "Find a repository":: a) type in: cti b) type in: dita c) type in: tosca That filter should work, and we designed the repository naming rules to exploit the GitHub org filter - Robin On Wed, Oct 5, 2016 at 9:46 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: The other aspect of this that should be considered by OASIS IMO, and why Mark's plan is very good - is that as these open repositories grow, it is going to quickly become a management headache under the current structure, because it lacks the ability to break things down by TC. Image our TC has 20 repos, another has 10, another has 15... quickly, when one goes to https://github.com/oasis-open/ , they will be confronted with a list of hundreds of repositories... as a user, how do I quickly filter this list to only contain only CTI TC items (or any other TC)? Whereas, if we use Mark's plan, all of the repos for a given TC are in one place, and it is easy as a user to find them on Github. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Mark Davidson ---10/05/2016 10:53:48 AM---Robin, My primary concern is that balloting seems slightly more heavyweight of a process than necess From: Mark Davidson < mdavidson@soltra.com > To: Robin Cover < robin@oasis-open.org > Cc: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >, Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Jason Keirstead/CanEast/IBM@IBMCA, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org > Date: 10/05/2016 10:53 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > Robin, My primary concern is that balloting seems slightly more heavyweight of a process than necessary for governing the GitHub Repos. To your main point, I do think there is a way to improve the process to a mutually agreeable end state. You raise some good questions, and I’d like to address them directly: > 1. Can you clarify that you make reference to GitHub repos that are used only by TC Members, governed by all OASIS policies (IPR, TC Process...) as opposed to "open" repositories that allow participation by anyone, via CLA, under open source licensing ? I am talking about GitHub repos that are governed by OASIS policies. I am under the impression that these repositories can be used by anyone. > 2. Can you explain why GitHub Project Pages will not work for the TCs? What features of Organization Pages are lacking in Project Pages [1]? There’s two reasons I’d like to consider one GitHub organization or the CTI TC (vs one GitHub org for all things OASIS) First - User, Project, and Organization pages differ in terms of the Hostname/URL that GitHub provides. Personally, I feel pretty strongly that our websites should have names that are short and easy to remember. In my opinion, e.g., https://oasis-open.github.io/ cti-documentation just will not stick with people the same way that https://stixproject.github.io sticks with people. There are other ways to achieve this – including a custom domain [1], but we should figure it out IMO. Second – The way people use GitHub, it (IMO) just makes more sense for related repos to be under a single GitHub organization and for unrelated repos to be located somewhere else. I’m interested in what other people think here (I’m just one opinon), but I’m strongly in favor of having one GitHub org for the CTI TC. > 3. Are you proposing that the repos you envision are NOT governed by OASIS rules? My apologies – I picked a bad example (repo deletion). My goal is a better process. In no way do I intend to circumvent or avoid the rules that we all agreed to support by joining OASIS. Thank you. -Mark [1] https://help.github.com/ articles/using-a-custom- domain-with-github-pages/ From: Robin Cover < robin@oasis-open.org > Date: Wednesday, October 5, 2016 at 9:04 AM To: Mark Davidson < mdavidson@soltra.com > Cc: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >, Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, Robin Cover < robin@oasis-open.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories Mark, I'll try to track with the conversation referenced below. We (OASIS) did consider several alternatives when designing the current plans for OASIS Open Repositories and (distinct from) GitHub Repos for TC work. Initially, two questions for you 1. Can you clarify that you make reference to GitHub repos that are used only by TC Members, governed by all OASIS policies (IPR, TC Process...) as opposed to "open" repositories that allow participation by anyone, via CLA, under open source licensing ? 2. Can you explain why GitHub Project Pages will not work for the TCs? What features of Organization Pages are lacking in Project Pages [1]? 3. Are you proposing that the repos you envision are NOT governed by OASIS rules? Foe example, you talk about repo deletion as a desirable feature ("t he operating rules can be superseded by a ballot on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted.." OASIS rules prohibit deletion of resources created by TC members [2] Comment: If you principal concern is about "ballots" (" A set of operating rules for managing repos that does NOT require a ballot"), then I think there is room within OASIS practice (and policy), perhaps with a few clarifications and updates, to allow most of what a TC wants to do -- without ballot. The matter of requiring a ballot for TC creation was raised earlier: under current OASIS rules, a "ballot" is not required for creation of an OASIS Open Repository or for the creation of a TC GitHub repo (repository for TC CHartered work). What's required is meeting minutes. We can clarify that further. That's all for now. Thanks, - Robin [1] https://help.github.com/ articles/user-organization- and-project-pages/#project- pages [2] http://docs.oasis-open.org/ specGuidelines/ndr/ namingDirectives.html# resourcePermanence Resource Permanence As part of the OASIS institutional commitment to transparency, openness, accountability, and public auditability, resources published in the OASIS Library, TC Document Repository, and other venues must not be deleted or otherwise altered. Resources may be revised, but all revisions are retained. With the exception of resources identified by "latest version" URI aliases, content instantiated as regular files and directories must not be over-written, replaced, renamed, or removed. TC Members are expected to follow this rule even in cases where a collaboration tool (by some means) might allow resource deletion or silent alteration. On Wed, Oct 5, 2016 at 7:30 AM, Mark Davidson < mdavidson@soltra.com > wrote: I realize this might go against the grain for some, but maybe we should talk about the organization of GitHub repos on the next working call. Personally, having one OASIS organization for _all_ GitHub repos is going to make tracking the work of any single TC more difficult. In addition, one OASIS organization prevents individual TCs from having *. github.io pages, which the STIX/TAXII group has made good use of in the past. I’d like it if we could consider a method that would provide the necessary governance AND make the management of GitHub repos a little less cumbersome. I don’t know if it’s feasible, but I’d be interested in exploring a structure that has the following properties: · A GitHub organization for the CTI TC (e.g., github.com/oasis-cti-tc/ ) · All CTI TC repos fall under the OASIS-CTI-TC GitHub Org · A set of operating rules for managing repos that does NOT require a ballot. Possible operating rules: o New repos require sponsorship by a co-chair and sign-off by the TC chair o Repo maintainer has some authority over who has which rights o Any part of the operating rules can be superseded by a ballot on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted) · Other considerations? Basically, my goal would be to free us up a bit in terms of repo management, while staying true to the intent of participating in OASIS. What do people think? Thank you. -Mark From: < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org > Date: Tuesday, October 4, 2016 at 7:02 PM To: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com > Cc: Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories Another resource on submodules "Working with submodules" (February 01, 2016) https://github.com/blog/2104- working-with-submodules -rcc On Tue, Oct 4, 2016 at 3:56 PM, Ted Bedwell (tebedwel) < tebedwel@cisco.com > wrote: For the other git neophytes out there: https://git-scm.com/book/en/ v2/Git-Tools-Submodules http://blogs.atlassian.com/ 2013/03/git-submodules- workflows-tips/ This seems like a viable approach. From: < cti@lists.oasis-open.org > on behalf of Terry MacDonald < terry.macdonald@cosive.com > Date: Tuesday, October 4, 2016 at 3:19 PM To: "Bret Jordan (CS)" < Bret_Jordan@symantec.com > Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories Couldn't we do a git repo containing submodules? Then each tool can have its own git repo, and it can be linked a submodules into the overall tools collection repo. This then makes it easy for everyone to get a copy of all three rows from one place, and yet we avoid the problems with many different people who only need access to parts of the git tree... Cheers Terry MacDonald Cosive On 4 Oct. 2016 9:09 am, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote: The problem with all of this is that it is not a collection of repos, but rather specific repos. Including multiple projects in a single repo is considered "bad form". Yes, you can do funky things with TAGS and you can even use different directories in the same repo. But that kind of break the git model. So instead of OASIS creating a oasis-open project with a bunch of arrant TC repos underneath, it seems like OASIS should setup a TC specific "projects". Then the TC can create as many repos on the project that it wants. Bret   From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org > Sent: Thursday, September 29, 2016 8:28:43 AM To: Jason Keirstead Cc: Kirillov, Ivan A.; Back, Greg; OASIS CTI TC Discussion List; Robin Cover Subject: Re: [cti] Status of CTI OASIS Open Repositories On Thu, Sep 29, 2016 at 9:14 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: RE " I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" " It is basically tied back to the need, currently, to be a TC member and make a motion if you want to make a new repository OK, I understand. I'll raise the issue with Staff: can/should we support some means whereby a non-TC Member can easily make request for a new OASIS Open Repository where it's perceived that no existing Open Repository repository is suitable. , combined with these repositories being tied to very specific projects and not having a generic top-level repository. In the case at hand: the CTI TC can create an OASIS Open Repository described as "generic": that is your choice. I suppose you could also characterize some new OASIS Open Repository as "top-level" (notionally) if the TC members wanted to do that. Imagine a non-TC member has some brand new code they want to contribute, but it does not fall into any of these existing open repository categories, and we have no "generic" type of repository. They can not make a new repository, or even motion to make one, as they are not a TC member. They're stuck. The only way they could donate this code, would be to try to proxy through another TC member to get the repository created for them to commit it to. I strongly suspect that instead of that hassle they would just put it up on their own Github. Thanks for the clarification via examples. I'll certainly raise the issue with Staff. All such suggestions for improvement are welcome. Kindest regards and best wishes, - Robin - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/29/2016 09:28:30 AM---On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/29/2016 09:28 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I hear what you are saying and there are definitely pros and cons to having some more generic repositories - but I am trying to envision the near future where we will hopefully have a whole bunch of various code contributions from vendors, members and hopefully non-members alike. This is just my opinion of course, but I think we should try to make the process to contribute code to the TC as light-weight as possible, to encourage people to contribute to our open repositories vs. just throw it up on their own Github account - as if they do that, then IPR and access is not as assured. Having to make a motion to create a new repository every time someone wants to contribute some new code, is a fairly heavyweight process in my opinion. It also means that only TC members can contribute any "new things", because the public can't trigger a vote on making a new repository - so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member). Jason, I'll raise the matter of requiring a motion/ballot with Staff. We probably want some kind of confirmation from the TC Chairs(s) -- indicating that there was consensus on the key elements of the request (name, Maintainers, choice of FOSS license, etc) Re: > a whole bunch of various code contributions from vendors, members and hopefully non-members alike That sounds great, and OASIS Open Repositories are intended to support that. It's a TC decision whether you want more or fewer repositories. It's a TC decision as to whether the repos are described as "generic" or having closely defined focus. I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" For the OASIS Open Repositories, once the repo is created, anyone from "the public" (non-TC member) can be a full participant, including Maintainer, per consensus. They can contribute "new things" in the same way as anyone can contribute new things to any GitHub public repository. Perhaps I misunderstand your concern.... I have assumed, maybe incorrectly, that your mention of a new repository (additional to those reported by Greg Back [1]) meant you want a new OASIS Open Repository ( https://www.oasis-open.org/ resources/open-repositories ) - Robin [1] cti-stix2-json-schemas cti-pattern-validator cti-marking-prototype cti-stix-visualization cti-stix-validator cti-documentation cti-cybox3-json-schemas - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/28/2016 10:35:01 PM---Jason, The decision about creating something like "stix-tools" is (of course) a From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/28/2016 10:35 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > Jason, The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race. Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository. One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent) design that uses folders within a single repository. Using separate repos means less work (design work, workday-work) when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo. Just use one taxonomy of types/labels without namespace worries. And: you can five write privs to relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects... But as always: it's up to the TC, and I am no expert here. - Robin On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Hello all; IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement. It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets? -- Sent from my mobile device, please excuse any typos. Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories --- From: "Kirillov, Ivan A." < ikirillov@mitre.org > To: "Back, Greg" < gback@mitre.org >, cti@lists.oasis-open.org Date: Wed, Sep 28, 2016 2:09 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-) Regards, Ivan On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org on behalf of Back, Greg" < cti@lists.oasis-open.org on behalf of gback@mitre.org > wrote: >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS. > >- cti-stix2-json-schemas >- cti-pattern-validator >- cti-marking-prototype >- cti-stix-visualization >- cti-stix-validator > >There are two other repositories that exist, but do not (yet) have any content: > >- cti-documentation >- cti-cybox3-json-schemas > >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor License Agreement (CLA): https://www.oasis-open.org/ resources/open-repositories/ cla . This applies *even to TC members*. > >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions about the process, etc. > >You can find the repositories here: https://github.com/oasis-open > >Thanks, > >Greg Back >MITRE > >----------------------------- ------------------------------ ---------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/ apps/org/workgroup/portal/my_ workgroups.php > -- -- -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/peo p le/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/new s letterArchive.html Tel: +1 972-296-1783 -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/peo p le/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/new s letterArchive.html Tel: +1 972-296-1783   -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/ people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/ newsletterArchive.html Tel: +1 972-296-1783 -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783


  • 21.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-05-2016 15:52




    FWIW I agree with Mark. A Github Organization per TC makes more sense to me from an organizational perspective.
     

    From:
    <cti@lists.oasis-open.org> on behalf of Robin Cover <robin@oasis-open.org>
    Date: Wednesday, October 5, 2016 at 11:48 AM
    To: Mark Davidson <mdavidson@soltra.com>
    Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Greg Back <gback@mitre.org>, Ivan Kirillov <ikirillov@mitre.org>, "Ted Bedwell (tebedwel)" <tebedwel@cisco.com>,
    Terry MacDonald <terry.macdonald@cosive.com>, Robin Cover <robin@oasis-open.org>
    Subject: Re: [cti] Status of CTI OASIS Open Repositories


     


    Mark asked:

     


    > ....  would that be possible? If that’s possible


     


    Mark, I think you are asking whether OASIS, as owner of the proposed Organization, would modify current policy/practice to create and support a new GitHub Organization for the CTI TC. 
    Is that correct?


     


    I am happy to bring this question to relevant OASIS Staff -- soon, or later -- if that is the question you are asking.


     


    I was rather expecting some additional feedback --  from others on the CTI TC who have significant experience with GitHub.


     


    Cheers,


     


    - Robin


     



    On Wed, Oct 5, 2016 at 10:40 AM, Mark Davidson < mdavidson@soltra.com > wrote:



    I guess at a high level, it boils down to: If the OASIS CTI TC were to, by consensus, desire a GitHub organization for itself,
    would that be possible? If that’s possible, I’m happy to make a motion or do whatever is the best way to establish whether we have consensus.
     
    Thank you.
    -Mark
     

    From:
    Robin Cover < robin@oasis-open.org >
    Date: Wednesday, October 5, 2016 at 11:11 AM
    To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >
    Cc: "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >,
    "Back, Greg" < gback@mitre.org >, "Kirillov, Ivan A." < ikirillov@mitre.org >, Mark Davidson < mdavidson@soltra.com >,
    "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >, Terry MacDonald < terry.macdonald@cosive.com >, Robin Cover < robin@oasis-open.org >
    Subject: Re: [cti] Status of CTI OASIS Open Repositories


     




    On Wed, Oct 5, 2016 at 10:01 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:


    I guess what I mean is... if I am "average joe", I am probably going to type "STIX" in that filter, not "cti".



     


    I admit the filter is not perfect


     


    But:


     


    Type in: stix


     


    -rcc


     




    -
    Jason Keirstead
    STSM, Product Architect, Security Intelligence, IBM Security Systems
    www.ibm.com/security
    www.securityintelligence.com

    Without data, all you are is just another person with an opinion - Unknown


    Robin Cover ---10/05/2016
    11:55:15 AM---I'm not implying blanket disagreement with Mark's idea, but to answer your question

    From: Robin Cover < robin@oasis-open.org >
    To: Jason Keirstead/CanEast/IBM@IBMCA
    Cc: Mark Davidson < mdavidson@soltra.com >, "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >,
    Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org "
    < cti@lists.oasis-open.org >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >,
    Robin Cover < robin@oasis-open.org >
    Date: 10/05/2016 11:55 AM
    Subject: Re: [cti] Status of CTI OASIS Open Repositories








    I'm not implying blanket disagreement with Mark's idea, but to answer your question

    > as a user, how do I quickly filter this list to only contain only CTI TC items (or any other TC)? 

    Go to:   https://github.com/oasis-open

    In the search box (upper left), "Filters" - "Find a repository"::

    a) type in: cti
    b) type in: dita
    c) type in: tosca

    That filter should work, and we designed the repository naming rules to exploit the GitHub org filter

    - Robin

    On Wed, Oct 5, 2016 at 9:46 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:


    The other aspect of this that should be considered by OASIS IMO, and why Mark's plan is very good - is that as these open repositories grow, it is going to quickly become a management headache under the current structure, because
    it lacks the ability to break things down by TC.

    Image our TC has 20 repos, another has 10, another has 15... quickly, when one goes to
    https://github.com/oasis-open/ , they will be confronted with a list of hundreds of repositories... as a user, how do I quickly
    filter this list to only contain only CTI TC items (or any other TC)?

    Whereas, if we use Mark's plan, all of the repos for a given TC are in one place, and it is easy as a user to find them on Github.

    -
    Jason Keirstead
    STSM, Product Architect, Security Intelligence, IBM Security Systems
    www.ibm.com/security
    www.securityintelligence.com

    Without data, all you are is just another person with an opinion - Unknown


    Mark
    Davidson ---10/05/2016 10:53:48 AM---Robin, My primary concern is that balloting seems slightly more heavyweight of a process than necess

    From: Mark Davidson < mdavidson@soltra.com >
    To: Robin Cover < robin@oasis-open.org >
    Cc: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >, Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >,
    " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Jason Keirstead/CanEast/IBM@IBMCA, "Kirillov, Ivan A." < ikirillov@mitre.org >,
    "Back, Greg" < gback@mitre.org >
    Date: 10/05/2016 10:53 AM
    Subject: Re: [cti] Status of CTI OASIS Open Repositories
    Sent by: < cti@lists.oasis-open.org >









    Robin,

    My primary concern is that balloting seems slightly more heavyweight of a process than necessary for governing the GitHub Repos. To your main point, I do think there is a way to improve the process to a mutually agreeable end state.

    You raise some good questions, and I’d like to address them directly:

    > 1. Can you clarify that you make reference to GitHub repos that are used only by TC Members, governed by all OASIS policies (IPR, TC Process...) as opposed to "open" repositories that allow participation by anyone, via CLA, under open source licensing ?

    I am talking about GitHub repos that are governed by OASIS policies. I am under the impression that these repositories can be used by anyone.

    > 2. Can you explain why GitHub Project Pages will not work for the TCs? What features of Organization Pages are lacking in Project Pages [1]?

    There’s two reasons I’d like to consider one GitHub organization or the CTI TC (vs one GitHub org for all things OASIS)

    First - User, Project, and Organization pages differ in terms of the Hostname/URL that GitHub provides. Personally, I feel pretty strongly that our websites should have names that are short and easy to remember. In my opinion, e.g.,
    https://oasis-open.github.io/cti-documentation just will not stick
    with people the same way that https://stixproject.github.io sticks with people.
    There are other ways to achieve this – including a custom domain [1], but we should figure it out IMO.

    Second – The way people use GitHub, it (IMO) just makes more sense for related repos to be under a single GitHub organization and for unrelated repos to be located somewhere else. I’m interested in what other people think here (I’m just one opinon), but I’m
    strongly in favor of having one GitHub org for the CTI TC.

    > 3. Are you proposing that the repos you envision are NOT governed by OASIS rules?

    My apologies – I picked a bad example (repo deletion). My goal is a better process. In no way do I intend to circumvent or avoid the rules that we all agreed to support by joining OASIS.

    Thank you.
    -Mark

    [1] https://help.github.com/articles/using-a-custom-domain-with-github-pages/

    From: Robin Cover < robin@oasis-open.org >
    Date: Wednesday, October 5, 2016 at 9:04 AM
    To: Mark Davidson < mdavidson@soltra.com >
    Cc: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >, Terry MacDonald < terry.macdonald@cosive.com >,
    "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org "
    < cti@lists.oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >,
    "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >,
    Robin Cover < robin@oasis-open.org >
    Subject: Re: [cti] Status of CTI OASIS Open Repositories

    Mark,

    I'll try to track with the conversation referenced below. We (OASIS) did consider several alternatives when designing the current plans for OASIS Open Repositories and (distinct from) GitHub Repos for TC work.

    Initially, two questions for you

    1. Can you clarify that you make reference to GitHub repos that are used only by TC Members, governed by all OASIS policies (IPR, TC Process...) as opposed to "open" repositories that allow participation by anyone, via CLA, under open source licensing ?

    2. Can you explain why GitHub Project Pages will not work for the TCs? What features of Organization Pages are lacking in Project Pages [1]?

    3. Are you proposing that the repos you envision are NOT governed by OASIS rules? Foe example, you talk about repo deletion as a desirable feature ("t he operating rules can be superseded by a ballot
    on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted.." OASIS rules prohibit deletion of resources created by TC members [2]

    Comment:

    If you principal concern is about "ballots" (" A set of operating rules for managing repos that does NOT require a ballot"), then I think there is room within OASIS practice (and policy), perhaps with
    a few clarifications and updates, to allow most of what a TC wants to do -- without ballot. The matter of requiring a ballot for TC creation was raised earlier: under current OASIS rules, a "ballot" is not required for creation of an OASIS Open Repository
    or for the creation of a TC GitHub repo (repository for TC CHartered work). What's required is meeting minutes. We can clarify that further.

    That's all for now.

    Thanks,

    - Robin

    [1] https://help.github.com/articles/user-organization-and-project-pages/#project-pages


    [2] http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#resourcePermanence

    Resource Permanence
    As part of the OASIS institutional commitment to transparency, openness, accountability, and public auditability, resources published in the OASIS Library, TC Document Repository, and other venues must not be deleted or otherwise altered. Resources may be revised,
    but all revisions are retained. With the exception of resources identified by "latest version" URI aliases, content instantiated as regular files and directories must not be over-written, replaced, renamed, or removed. TC Members are expected to follow this
    rule even in cases where a collaboration tool (by some means) might allow resource deletion or silent alteration.


    On Wed, Oct 5, 2016 at 7:30 AM, Mark Davidson < mdavidson@soltra.com > wrote:
    I realize this might go against the grain for some, but maybe we should talk about the organization of GitHub repos on the next working call. Personally, having one OASIS organization for _all_ GitHub repos is going to make tracking the work of any single TC
    more difficult. In addition, one OASIS organization prevents individual TCs from having *. github.io
    pages, which the STIX/TAXII group has made good use of in the past. I’d like it if we could consider a method that would provide the necessary governance AND make the management of GitHub repos a little less cumbersome.

    I don’t know if it’s feasible, but I’d be interested in exploring a structure that has the following properties:

    ·
    A GitHub organization for the CTI TC (e.g.,
    github.com/oasis-cti-tc/ )
    ·
    All CTI TC repos fall under the OASIS-CTI-TC GitHub Org
    ·
    A set of operating rules for managing repos that does NOT require a ballot. Possible operating rules:

    o
    New repos require sponsorship by a co-chair and sign-off by the TC chair

    o
    Repo maintainer has some authority over who has which rights
    o
    Any part of the operating rules can be superseded by a ballot on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted)

    ·
    Other considerations?

    Basically, my goal would be to free us up a bit in terms of repo management, while staying true to the intent of participating in OASIS. What do people think?

    Thank you.
    -Mark

    From: < cti@lists.oasis-open.org >
    on behalf of Robin Cover < robin@oasis-open.org >
    Date: Tuesday, October 4, 2016 at 7:02 PM
    To: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com >
    Cc: Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >,
    " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >,
    Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >,
    "Back, Greg" < gback@mitre.org >
    Subject: Re: [cti] Status of CTI OASIS Open Repositories

    Another resource on submodules

    "Working with submodules" (February 01, 2016)
    https://github.com/blog/2104-working-with-submodules

    -rcc

    On Tue, Oct 4, 2016 at 3:56 PM, Ted Bedwell (tebedwel) < tebedwel@cisco.com > wrote:


    For the other git neophytes out there:
    https://git-scm.com/book/en/v2/Git-Tools-Submodules
    http://blogs.atlassian.com/2013/03/git-submodules-workflows-tips/

    This seems like a viable approach.

    From: < cti@lists.oasis-open.org >
    on behalf of Terry MacDonald < terry.macdonald@cosive.com >
    Date: Tuesday, October 4, 2016 at 3:19 PM
    To: "Bret Jordan (CS)" < Bret_Jordan@symantec.com >
    Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >,
    Robin Cover < robin@oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >,
    "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >
    Subject: Re: [cti] Status of CTI OASIS Open Repositories
    Couldn't we do a git repo containing submodules? Then each tool can have its own git repo, and it can be linked a submodules into the overall tools collection repo.

    This then makes it easy for everyone to get a copy of all three rows from one place, and yet we avoid the problems with many different people who only need access to parts of the git tree...
    Cheers
    Terry MacDonald
    Cosive

    On 4 Oct. 2016 9:09 am, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote:
    The problem with all of this is that it is not a collection of repos, but rather specific repos. Including multiple projects in a single repo is considered "bad form". Yes, you can do funky things with TAGS and you can even use different directories in the
    same repo. But that kind of break the git model. So instead of OASIS creating a oasis-open project with a bunch of arrant TC repos underneath, it seems like OASIS should setup a TC specific "projects". Then the TC can create as many repos on the project that
    it wants.
    Bret

     






    From:
    cti@lists.oasis-open.org < cti@lists.oasis-open.org >
    on behalf of Robin Cover < robin@oasis-open.org >
    Sent: Thursday, September 29, 2016 8:28:43 AM
    To: Jason Keirstead
    Cc: Kirillov, Ivan A.; Back, Greg; OASIS CTI TC Discussion List; Robin Cover
    Subject: Re: [cti] Status of CTI OASIS Open Repositories


    On Thu, Sep 29, 2016 at 9:14 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:
    RE " I don't quite understand your meaning here:


    "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" "

    It is basically tied back to the need, currently, to be a TC member and make a motion if you want to make a new repository
    OK, I understand. I'll raise the issue with Staff: can/should we support some means whereby a non-TC Member can easily make request for a new OASIS Open Repository where it's perceived that no existing Open Repository repository is suitable.
    , combined with these repositories being tied to very specific projects and not having a generic top-level repository.
    In the case at hand: the CTI TC can create an OASIS Open Repository described as "generic": that is your choice. I suppose you could also characterize some new OASIS Open Repository as "top-level" (notionally) if the TC members wanted to do that.


    Imagine a non-TC member has some brand new code they want to contribute, but it does not fall into any of these existing open repository categories, and we have no "generic" type of repository. They can not make a new repository, or even motion to make one,
    as they are not a TC member. They're stuck. The only way they could donate this code, would be to try to proxy through another TC member to get the repository created for them to commit it to. I strongly suspect that instead of that hassle they would just
    put it up on their own Github.

    Thanks for the clarification via examples. I'll certainly raise the issue with Staff. All such suggestions for improvement are welcome.

    Kindest regards and best wishes,

    - Robin



    -
    Jason Keirstead
    STSM, Product Architect, Security Intelligence, IBM Security Systems
    www.ibm.com/security
    www.securityintelligence.com

    Without data, all you are is just another person with an opinion - Unknown


    Robin
    Cover ---09/29/2016 09:28:30 AM---On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com
    > wrote:

    From: Robin Cover < robin@oasis-open.org >
    To: Jason Keirstead/CanEast/IBM@IBMCA
    Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >,
    OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org >
    Date: 09/29/2016 09:28 AM
    Subject: Re: [cti] Status of CTI OASIS Open Repositories
    Sent by: < cti@lists.oasis-open.org >










    On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:


    I hear what you are saying and there are definitely pros and cons to having some more generic repositories - but I am trying to envision the near future where we will hopefully have a whole bunch of various code contributions
    from vendors, members and hopefully non-members alike. This is just my opinion of course, but I think we should try to make the process to contribute code to the TC as light-weight as possible, to encourage people to contribute to our open repositories vs.
    just throw it up on their own Github account - as if they do that, then IPR and access is not as assured. Having to make a motion to create a new repository every time someone wants to contribute some new code, is a fairly heavyweight process in my opinion.
    It also means that only TC members can contribute any "new things", because the public can't trigger a vote on making a new repository - so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they
    proxy through a member).


    Jason, I'll raise the matter of requiring a motion/ballot with Staff. We probably want some kind of confirmation from the TC Chairs(s) -- indicating that there was consensus on the key elements of the request (name, Maintainers, choice of FOSS license, etc)

    Re:
    > a whole bunch of various code contributions from vendors, members and hopefully non-members alike

    That sounds great, and OASIS Open Repositories are intended to support that. It's a TC decision whether you want more or fewer repositories. It's a TC decision as to whether the repos are described as "generic" or having closely defined focus.

    I don't quite understand your meaning here:

    "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)"

    For the OASIS Open Repositories, once the repo is created, anyone from "the public" (non-TC member) can be a full participant, including Maintainer, per consensus. They can contribute "new things" in the same way as anyone can contribute new things to any GitHub
    public repository. Perhaps I misunderstand your concern....

    I have assumed, maybe incorrectly, that your mention of a new repository (additional to those reported by Greg Back [1]) meant you want a new OASIS Open Repository (
    https://www.oasis-open.org/resources/open-repositories )

    - Robin


    [1]

    cti-stix2-json-schemas
    cti-pattern-validator
    cti-marking-prototype
    cti-stix-visualization
    cti-stix-validator
    cti-documentation
    cti-cybox3-json-schemas


    -
    Jason Keirstead
    STSM, Product Architect, Security Intelligence, IBM Security Systems
    www.ibm.com/security
    www.securityintelligence.com

    Without data, all you are is just another person with an opinion - Unknown


    Robin
    Cover ---09/28/2016 10:35:01 PM---Jason, The decision about creating something like "stix-tools" is (of course) a

    From: Robin Cover < robin@oasis-open.org >
    To: Jason Keirstead/CanEast/IBM@IBMCA
    Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >,
    OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org >
    Date: 09/28/2016 10:35 PM
    Subject: Re: [cti] Status of CTI OASIS Open Repositories
    Sent by: < cti@lists.oasis-open.org >










    Jason,

    The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race.

    Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository.

    One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent) design that uses folders within a single repository. Using separate repos means less work (design work, workday-work)
    when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo. Just use one taxonomy of types/labels without namespace worries. And: you can five write privs to
    relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects...

    But as always: it's up to the TC, and I am no expert here.

    - Robin

    On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:


    Hello all;

    IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement.

    It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets?

    --
    Sent from my mobile device, please excuse any typos.

    Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories ---






    From:



    "Kirillov, Ivan A." < ikirillov@mitre.org >





    To:



    "Back, Greg" < gback@mitre.org >,
    cti@lists.oasis-open.org





    Date:



    Wed, Sep 28, 2016 2:09 PM





    Subject:



    Re: [cti] Status of CTI OASIS Open Repositories












    Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-)

    Regards,
    Ivan

    On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org on behalf of Back,
    Greg" < cti@lists.oasis-open.org on behalf of
    gback@mitre.org > wrote:

    >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS.

    >
    >- cti-stix2-json-schemas
    >- cti-pattern-validator
    >- cti-marking-prototype
    >- cti-stix-visualization
    >- cti-stix-validator
    >
    >There are two other repositories that exist, but do not (yet) have any content:
    >
    >- cti-documentation
    >- cti-cybox3-json-schemas
    >
    >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor
    License Agreement (CLA): https://www.oasis-open.org/resources/open-repositories/cla
    . This applies *even to TC members*.
    >
    >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions
    about the process, etc.
    >
    >You can find the repositories here: https://github.com/oasis-open

    >
    >Thanks,
    >
    >Greg Back
    >MITRE
    >
    >---------------------------------------------------------------------
    >To unsubscribe from this mail list, you must leave the OASIS TC that
    >generates this mail. Follow this link to all your TCs in OASIS at:
    > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

    >




    --





    --




    --
    Robin Cover
    OASIS, Director of Information Services
    Editor, Cover Pages and XML Daily Newslink
    Email:
    robin@oasis-open.org
    Staff bio:
    http://www.oasis-open.org/peo p le/staff/robin-cover
    Cover Pages:
    http://xml.coverpages.org/
    Newsletter:
    http://xml.coverpages.org/new s letterArchive.html
    Tel: +1
    972-296-1783




    --

    Robin Cover
    OASIS, Director of Information Services
    Editor, Cover Pages and XML Daily Newslink
    Email:
    robin@oasis-open.org
    Staff bio:
    http://www.oasis-open.org/peo p le/staff/robin-cover
    Cover Pages:
    http://xml.coverpages.org/
    Newsletter:
    http://xml.coverpages.org/new s letterArchive.html
    Tel:
    +1 972-296-1783







     

    --


    Robin Cover
    OASIS, Director of Information Services
    Editor, Cover Pages and XML Daily Newslink
    Email: robin@oasis-open.org
    Staff bio:
    http://www.oasis-open.org/people/staff/robin-cover
    Cover Pages: http://xml.coverpages.org/
    Newsletter:
    http://xml.coverpages.org/newsletterArchive.html
    Tel: +1 972-296-1783











     

    --

    Robin Cover
    OASIS, Director of Information Services
    Editor, Cover Pages and XML Daily Newslink
    Email: robin@oasis-open.org
    Staff bio:
    http://www.oasis-open.org/people/staff/robin-cover
    Cover Pages: http://xml.coverpages.org/
    Newsletter:
    http://xml.coverpages.org/newsletterArchive.html
    Tel: +1 972-296-1783









  • 22.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-10-2016 07:42
    On 05.10.2016 15:51:58, Wunder, John A. wrote: > FWIW I agree with Mark. A Github Organization per TC makes more > sense to me from an organizational perspective. > Ditto, I'm in 100% agreement with Mark on this. -- Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- "For all resources, whatever it is, you need more." --RFC 1925 Attachment: signature.asc Description: Digital signature


  • 23.  RE: [cti] Status of CTI OASIS Open Repositories

    Posted 10-10-2016 19:27
    Trey, John, Mark- Just to be clear, which of the following are you talking about? 1. an organization for the TC's chartered work, to be used instead of https://github.com/oasis-tcs 2. an organization for open source code related to the TC's chartered work, but not subject to the normal TC IPR policies, to be used instead of https://github.com/oasis-open/ 3. both (though I believe that the two would likely need to be kept separate to comply with OASIS policies) Specifically regarding #2, the strongest argument I've heard is that it would help keep the CTI open source repos separate from other TC's, even though this can easily be done by searching for "cti-" [1]. From a user standpoint, nearly all interaction with GitHub is done on a per-repository basis, not per-organization. You can't watch, star, or fork an organization, nor I have I seen any way to automatically follow new repos that get created in an organization. The only exception is the "dashboard" view ( https://github.com/orgs/ <ORGNAME>/dashboard), which is only available to members of the organization. For Open Repositories, under current policies only the maintainers become members of the organization. I personally never use the dashboard view for any organizations I am a member of. The result is that each repository would need to be handled individually, regardless of whether it's in the same organization as repositories sponsored by other TCs. On the other hand, in my experience maintaining multiple organizations is significantly more work than maintaining multiple teams within the same organization. Since I imagine OASIS staff will be maintaining these organizations, I'd like to make it as easy on them as possible. The argument for a separate organization for chartered work (option #1) is a bit stronger, particularly since there's nothing in that organization yet, but I still don't really see the benefits. Greg [1] https://github.com/oasis-open/?query=cti- >
    Original Message


  • 24.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-10-2016 20:09
    I disagree.  It would make things a lot easier if the Chartered work repos were done as TC level projects instead of individual repos.   Further, I think this TC should create an open source project on github that is outside of OASIS for all of our opensource projects and contributions that come from MITRE or others.  Bret From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Back, Greg <gback@mitre.org> Sent: Monday, October 10, 2016 1:25:45 PM To: Trey Darley; Wunder, John A.; Mark Davidson; cti@lists.oasis-open.org Subject: RE: [cti] Status of CTI OASIS Open Repositories   Trey, John, Mark- Just to be clear, which of the following are you talking about? 1. an organization for the TC's chartered work, to be used instead of https://github.com/oasis-tcs 2. an organization for open source code related to the TC's chartered work, but not subject to the normal TC IPR policies, to be used instead of https://github.com/oasis-open/ 3. both (though I believe that the two would likely need to be kept separate to comply with OASIS policies) Specifically regarding #2, the strongest argument I've heard is that it would help keep the CTI open source repos separate from other TC's, even though this can easily be done by searching for "cti-" [1]. From a user standpoint, nearly all interaction with GitHub is done on a per-repository basis, not per-organization. You can't watch, star, or fork an organization, nor I have I seen any way to automatically follow new repos that get created in an organization. The only exception is the "dashboard" view ( https://github.com/orgs/<ORGNAME>/dashboard ), which is only available to members of the organization. For Open Repositories, under current policies only the maintainers become members of the organization. I personally never use the dashboard view for any organizations I am a member of. The result is that each repository would need to be handled individually, regardless of whether it's in the same organization as repositories sponsored by other TCs. On the other hand, in my experience maintaining multiple organizations is significantly more work than maintaining multiple teams within the same organization. Since I imagine OASIS staff will be maintaining these organizations, I'd like to make it as easy on them as possible. The argument for a separate organization for chartered work (option #1) is a bit stronger, particularly since there's nothing in that organization yet, but I still don't really see the benefits. Greg [1] https://github.com/oasis-open/?query=cti- >
    Original Message


  • 25.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-10-2016 23:32
    On 10/10/2016 3:08 PM, Bret Jordan (CS) wrote: I disagree. It would make things a lot easier if the Chartered work repos were done as TC level projects instead of individual repos. What specifically would be easier? What specifically are we trying to do with Chartered Work repos? I would not recommend using them for prose specifications, unless we're planning to develop the specifications as Markdown, HTML, or some other plain text format. I've been given the impression that we don't want to include JSON schemas as chartered work products, hence why cti-stix2-json-schemas and cti-cybox3-json-schemas [sic] are open repositories. Further, I think this TC should create an open source project on github that is outside of OASIS for all of our opensource projects and contributions that come from MITRE or others. The MITRE members of the TC have made an explicit decision to contribute our code to OASIS Open repos, rather than (for instance) continuing to use STIXProject. What does being "outside of OASIS" gain us? What does it even mean for "the TC" to create something outside of OASIS (and therefore outside the TC)? As I've said before, anyone (including a TC member) is of course free to create whatever repositories they'd like. ---------- I'd still appreciate hearing from Mark, John, and/or Trey. Greg


  • 26.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-10-2016 23:38
    The chartered work repos have one primary purpose for us, and that is issue tracking against the published specifications.  We may use them for wikis or other things over time, but for the foreseeable future they will be used for issue tracking. Bret  Sent from my Commodore 64 PGP Fingerprint:  63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 On Oct 10, 2016, at 5:33 PM, Greg Back < gback@mitre.org > wrote: On 10/10/2016 3:08 PM, Bret Jordan (CS) wrote: I disagree.  It would make things a lot easier if the Chartered work repos were done as TC level projects instead of individual repos. What specifically would be easier? What specifically are we trying to do with Chartered Work repos? I would not recommend using them for prose specifications, unless we're planning to develop the specifications as Markdown, HTML, or some other plain text format.  I've been given the impression that we don't want to include JSON schemas as chartered work products, hence why cti-stix2-json-schemas and cti-cybox3-json-schemas [sic] are open repositories. Further, I think this TC should create an open source project on github that is outside of OASIS for all of our opensource projects and contributions that come from MITRE or others. The MITRE members of the TC have made an explicit decision to contribute our code to OASIS Open repos, rather than (for instance) continuing to use STIXProject. What does being "outside of OASIS" gain us? What does it even mean for "the TC" to create something outside of OASIS (and therefore outside the TC)? As I've said before, anyone (including a TC member) is of course free to create whatever repositories they'd like. ---------- I'd still appreciate hearing from Mark, John, and/or Trey. Greg


  • 27.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-11-2016 11:57




    I think having one global org for every TC is a negative for usability and will decrease the quality of the interaction our TC has with the outside world.
     
    A semi-technical (or technical) non-TC member who is trying to learn more about STIX and TAXII will not, at first, be guaranteed to understand what OASIS is or understand OASIS’ role in
    the development and governance of STIX and TAXII. Requiring knowledge about OASIS and its relationship to STIX/TAXII – i.e., understanding that https://github.com/oasis-open/ is where you find STIX and TAXII open source repositories (or further, that they
    have a CTI prefix) – is just not going to happen for the majority of people.
     
    We should be making the work produced by this TC as accessible as possible to the people outside this TC. We are not doing this work only for ourselves. I think we’ve demonstrated this
    already with the CybOX merger into STIX, so let’s keep going. FWIW, I agree with previous posts stating that the two approaches are roughly equivalent for TC members. I just think we need to focus on the external/outsider persona – they are the ones who need
    the most help consuming and understanding the work we are producing, and we should make it as easy as possible for them.
     
    Thank you.
    -Mark
     

    From:
    <cti@lists.oasis-open.org> on behalf of "Bret Jordan (CS)" <Bret_Jordan@symantec.com>
    Date: Monday, October 10, 2016 at 7:37 PM
    To: Greg Back <gback@mitre.org>
    Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
    Subject: Re: [cti] Status of CTI OASIS Open Repositories


     


    The chartered work repos have one primary purpose for us, and that is issue tracking against the published specifications.  We may use them for wikis or other things over time, but for the foreseeable future they will be used for issue
    tracking.


     


    Bret 

    Sent from my Commodore 64

     


    PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050






    On Oct 10, 2016, at 5:33 PM, Greg Back < gback@mitre.org > wrote:



    On 10/10/2016 3:08 PM, Bret Jordan (CS) wrote:



    I disagree.  It would make things a lot easier if the Chartered work


    repos were done as TC level projects instead of individual repos.


    What specifically would be easier?

    What specifically are we trying to do with Chartered Work repos? I would not recommend using them for prose specifications, unless we're planning to develop the specifications as Markdown, HTML, or some other plain text format.  I've been given the impression
    that we don't want to include JSON schemas as chartered work products, hence why cti-stix2-json-schemas and cti-cybox3-json-schemas [sic] are open repositories.




    Further, I think this TC should create an open source project on github


    that is outside of OASIS for all of our opensource projects and


    contributions that come from MITRE or others.


    The MITRE members of the TC have made an explicit decision to contribute our code to OASIS Open repos, rather than (for instance) continuing to use STIXProject.

    What does being "outside of OASIS" gain us? What does it even mean for "the TC" to create something outside of OASIS (and therefore outside the TC)? As I've said before, anyone (including a TC member) is of course free to create whatever repositories they'd
    like.

    ----------

    I'd still appreciate hearing from Mark, John, and/or Trey.

    Greg








  • 28.  RE: [cti] Status of CTI OASIS Open Repositories

    Posted 10-11-2016 13:23
    Thanks, Mark. In terms of "learning more about STIX and TAXII", I wouldn't expect anyone (technical or otherwise) to use GitHub as a starting point... except maybe to a web page hosted on GitHub Pages, at which point GitHub is mostly irrelevant. I also feel like the relationship of STIX and TAXII to OASIS is an asset rather than a liability; people do not necessarily need to understand OASIS in order to understand STIX and TAXII, but having the work affiliated with OASIS lends credibility to the work we are doing. Furthermore, I expect anyone looking for information about STIX and TAXII will use a search engine, which should be equally capable of finding the content regardless of where it's hosted. A simple landing page accessible from an easily-remembered URL (like http://cti-tc.github.io ) should serve to direct people to all content produced by the TC and its members). If the biggest barrier to becoming involved is not understanding the relationship to OASIS (meaning that everything else we've done is crystal-clear), I'd consider that a monumental victory. Greg >
    Original Message


  • 29.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-11-2016 17:09
    Greg it is more than that.  Under the current setup, with using OASIS open repos, people need to sign OASIS paper to contribute.  This is a monumental barrier that some organizations will not cross.  Basically the bigger the org the more likely your OGC will not allow you to do that.   We also need to remember what Rich S always said.  OASIS is for people that want to work on the standards.  But for everything else, there is a huge community that is 2-3 orders of magnitude larger.  We need to make sure the production side of STIX and TAXII is easy to use and contribute to. Bret From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Back, Greg <gback@mitre.org> Sent: Tuesday, October 11, 2016 7:22:49 AM To: Mark Davidson Cc: cti@lists.oasis-open.org Subject: RE: [cti] Status of CTI OASIS Open Repositories   Thanks, Mark. In terms of "learning more about STIX and TAXII", I wouldn't expect anyone (technical or otherwise) to use GitHub as a starting point... except maybe to a web page hosted on GitHub Pages, at which point GitHub is mostly irrelevant. I also feel like the relationship of STIX and TAXII to OASIS is an asset rather than a liability; people do not necessarily need to understand OASIS in order to understand STIX and TAXII, but having the work affiliated with OASIS lends credibility to the work we are doing. Furthermore, I expect anyone looking for information about STIX and TAXII will use a search engine, which should be equally capable of finding the content regardless of where it's hosted. A simple landing page accessible from an easily-remembered URL (like http://cti-tc.github.io ) should serve to direct people to all content produced by the TC and its members). If the biggest barrier to becoming involved is not understanding the relationship to OASIS (meaning that everything else we've done is crystal-clear), I'd consider that a monumental victory. Greg >
    Original Message


  • 30.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-12-2016 09:04
    Yes, and the Github project we setup for opensource tools, things not part of the standards work, should NOT be part of the OASIS OPEN repo stuff.  This tightly couples this open source work to OASIS and means that organizations and individuals will have to SIGN OASIS legal documents to contribute.  That is just NOT going to fly.   I so move that this TC approve the creation of a Github project outside of OASIS open repos (native github project) to be managed and maintained by the co-chairs for the use of all TC members and non-tc members that are not part of OASIS.  Further, I move that the license for all code in this repo be Apache2 licensed. This would allow us to stop using the OASIS open repos and thus remove a lot of the confusion.   Bret From: Mark Davidson <mdavidson@soltra.com> Sent: Tuesday, October 11, 2016 5:56:56 AM To: Bret Jordan (CS); Greg Back Cc: cti@lists.oasis-open.org Subject: Re: [cti] Status of CTI OASIS Open Repositories   I think having one global org for every TC is a negative for usability and will decrease the quality of the interaction our TC has with the outside world.   A semi-technical (or technical) non-TC member who is trying to learn more about STIX and TAXII will not, at first, be guaranteed to understand what OASIS is or understand OASIS’ role in the development and governance of STIX and TAXII. Requiring knowledge about OASIS and its relationship to STIX/TAXII – i.e., understanding that https://github.com/oasis-open/ is where you find STIX and TAXII open source repositories (or further, that they have a CTI prefix) – is just not going to happen for the majority of people.   We should be making the work produced by this TC as accessible as possible to the people outside this TC. We are not doing this work only for ourselves. I think we’ve demonstrated this already with the CybOX merger into STIX, so let’s keep going. FWIW, I agree with previous posts stating that the two approaches are roughly equivalent for TC members. I just think we need to focus on the external/outsider persona – they are the ones who need the most help consuming and understanding the work we are producing, and we should make it as easy as possible for them.   Thank you. -Mark   From: <cti@lists.oasis-open.org> on behalf of "Bret Jordan (CS)" <Bret_Jordan@symantec.com> Date: Monday, October 10, 2016 at 7:37 PM To: Greg Back <gback@mitre.org> Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: Re: [cti] Status of CTI OASIS Open Repositories   The chartered work repos have one primary purpose for us, and that is issue tracking against the published specifications.  We may use them for wikis or other things over time, but for the foreseeable future they will be used for issue tracking.   Bret  Sent from my Commodore 64   PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 On Oct 10, 2016, at 5:33 PM, Greg Back < gback@mitre.org > wrote: On 10/10/2016 3:08 PM, Bret Jordan (CS) wrote: I disagree.  It would make things a lot easier if the Chartered work repos were done as TC level projects instead of individual repos. What specifically would be easier? What specifically are we trying to do with Chartered Work repos? I would not recommend using them for prose specifications, unless we're planning to develop the specifications as Markdown, HTML, or some other plain text format.  I've been given the impression that we don't want to include JSON schemas as chartered work products, hence why cti-stix2-json-schemas and cti-cybox3-json-schemas [sic] are open repositories. Further, I think this TC should create an open source project on github that is outside of OASIS for all of our opensource projects and contributions that come from MITRE or others. The MITRE members of the TC have made an explicit decision to contribute our code to OASIS Open repos, rather than (for instance) continuing to use STIXProject. What does being "outside of OASIS" gain us? What does it even mean for "the TC" to create something outside of OASIS (and therefore outside the TC)? As I've said before, anyone (including a TC member) is of course free to create whatever repositories they'd like. ---------- I'd still appreciate hearing from Mark, John, and/or Trey. Greg


  • 31.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-12-2016 09:12
    On 11.10.2016 17:04:19, Bret Jordan (CS) wrote: > > I so move that this TC approve the creation of a Github project > outside of OASIS open repos (native github project) to be managed > and maintained by the co-chairs for the use of all TC members and > non-tc members that are not part of OASIS. Further, I move that the > license for all code in this repo be Apache2 licensed. > Hey, Bret - Don't you mean a Github *organization*, not a project? If so, either OASIS pays for it or somebody else (Symantec?) does. Unless OASIS pays for it and administers it as a neutral third party, I'm not sure folks will be entirely comfortable with a setup controlled by an individual vendor. -- Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- "A project is sustainable if it is cheap enough to be the first of a series continuing indefinitely into the future. A project is unsustainable if it is so expensive that it cannot be repeated without major political battles. A sustainable project marks the beginning of a new era. An unsustainable project marks the end of an old era." --Freeman Dyson Attachment: signature.asc Description: Digital signature


  • 32.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-12-2016 10:16
    I disagree Bret. There will be a limited number of people contributing to these repos. You have to be in pretty deep with STIX and TAXII to even want to contribute to these repos. You can't just say that people won't want to sign OASIS legal documents to want to contribute. I already have, and we don't even have a repo I can contribute to. I think it CAN fly. The point of OASIS is that it is neutral. We need to be very careful to maintain that neutrality in any repos that are associated with the CTI. That is, in my opinion, more important than people finding it difficult to sign a legal agreement. Cheers Terry MacDonald Cosive On 12 Oct. 2016 10:04 pm, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote: Yes, and the Github project we setup for opensource tools, things not part of the standards work, should NOT be part of the OASIS OPEN repo stuff.  This tightly couples this open source work to OASIS and means that organizations and individuals will have to SIGN OASIS legal documents to contribute.  That is just NOT going to fly.   I so move that this TC approve the creation of a Github project outside of OASIS open repos (native github project) to be managed and maintained by the co-chairs for the use of all TC members and non-tc members that are not part of OASIS.  Further, I move that the license for all code in this repo be Apache2 licensed. This would allow us to stop using the OASIS open repos and thus remove a lot of the confusion.   Bret From: Mark Davidson < mdavidson@soltra.com > Sent: Tuesday, October 11, 2016 5:56:56 AM To: Bret Jordan (CS); Greg Back Cc: cti@lists.oasis-open.org Subject: Re: [cti] Status of CTI OASIS Open Repositories   I think having one global org for every TC is a negative for usability and will decrease the quality of the interaction our TC has with the outside world.   A semi-technical (or technical) non-TC member who is trying to learn more about STIX and TAXII will not, at first, be guaranteed to understand what OASIS is or understand OASIS’ role in the development and governance of STIX and TAXII. Requiring knowledge about OASIS and its relationship to STIX/TAXII – i.e., understanding that https://github.com/oasis-open/ is where you find STIX and TAXII open source repositories (or further, that they have a CTI prefix) – is just not going to happen for the majority of people.   We should be making the work produced by this TC as accessible as possible to the people outside this TC. We are not doing this work only for ourselves. I think we’ve demonstrated this already with the CybOX merger into STIX, so let’s keep going. FWIW, I agree with previous posts stating that the two approaches are roughly equivalent for TC members. I just think we need to focus on the external/outsider persona – they are the ones who need the most help consuming and understanding the work we are producing, and we should make it as easy as possible for them.   Thank you. -Mark   From: < cti@lists.oasis-open.org > on behalf of "Bret Jordan (CS)" < Bret_Jordan@symantec.com > Date: Monday, October 10, 2016 at 7:37 PM To: Greg Back < gback@mitre.org > Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories   The chartered work repos have one primary purpose for us, and that is issue tracking against the published specifications.  We may use them for wikis or other things over time, but for the foreseeable future they will be used for issue tracking.   Bret  Sent from my Commodore 64   PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 On Oct 10, 2016, at 5:33 PM, Greg Back < gback@mitre.org > wrote: On 10/10/2016 3:08 PM, Bret Jordan (CS) wrote: I disagree.  It would make things a lot easier if the Chartered work repos were done as TC level projects instead of individual repos. What specifically would be easier? What specifically are we trying to do with Chartered Work repos? I would not recommend using them for prose specifications, unless we're planning to develop the specifications as Markdown, HTML, or some other plain text format.  I've been given the impression that we don't want to include JSON schemas as chartered work products, hence why cti-stix2-json-schemas and cti-cybox3-json-schemas [sic] are open repositories. Further, I think this TC should create an open source project on github that is outside of OASIS for all of our opensource projects and contributions that come from MITRE or others. The MITRE members of the TC have made an explicit decision to contribute our code to OASIS Open repos, rather than (for instance) continuing to use STIXProject. What does being "outside of OASIS" gain us? What does it even mean for "the TC" to create something outside of OASIS (and therefore outside the TC)? As I've said before, anyone (including a TC member) is of course free to create whatever repositories they'd like. ---------- I'd still appreciate hearing from Mark, John, and/or Trey. Greg


  • 33.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-11-2016 11:45
    On 10.10.2016 19:25:45, Back, Greg wrote: > Just to be clear, which of the following are you talking about? > > 1. an organization for the TC's chartered work, to be used instead > of https://github.com/oasis-tcs > > 2. an organization for open source code related to the TC's > chartered work, but not subject to the normal TC IPR policies, to be > used instead of https://github.com/oasis-open/ > > 3. both (though I believe that the two would likely need to be kept > separate to comply with OASIS policies) > Hi, Greg - I *thought* we were talking about #2. The biggest advantage I see is the ability to deal with issues and pull requests from non-TC members on open source projects initiated up by TC members. If we're going down the road of hosting things like the STIX 1=>2 upgrade utility and the STIX Patterning reference implementation, eventually (I suppose) the next generation of python-stix and libtaxii, then the entire ecosystem (including the TC membership) stands to gain by making it straightforward for non-TC members to contribute bug fixes and feature enhancements to these open source tools. I am *not* including things like JSON schemata and STIX/TAXII issue tracking in this category. I fully support the stuff that really falls under the rubric of the standards being subject to the normal IPR rules. > > Specifically regarding #2, the strongest argument I've heard is that > it would help keep the CTI open source repos separate from other > TC's, even though this can easily be done by searching for "cti-" > [1]. From a user standpoint, nearly all interaction with GitHub is > done on a per-repository basis, not per-organization. You can't > watch, star, or fork an organization, nor I have I seen any way to > automatically follow new repos that get created in an organization. > The only exception is the "dashboard" view > ( https://github.com/orgs/ <ORGNAME>/dashboard), which is only > available to members of the organization. For Open Repositories, > under current policies only the maintainers become members of the > organization. I personally never use the dashboard view for any > organizations I am a member of. The result is that each repository > would need to be handled individually, regardless of whether it's in > the same organization as repositories sponsored by other TCs. > That's your experience, Greg. Mine differs. While I do often interact directly with a single Git repository, I also frequently look at the parent Github org for new and interesting projects or when I forget the name of a specific project. Interested to hear what others have to say. > > On the other hand, in my experience maintaining multiple > organizations is significantly more work than maintaining multiple > teams within the same organization. Since I imagine OASIS staff will > be maintaining these organizations, I'd like to make it as easy on > them as possible. > If OASIS sets up a TC-specific Github organization for supporting open source tools and libraries, they can delegate the day-to-day maintenance of that to trusted members of the CTI TC, given that we establish a clear line as to what falls under the rubric of the standards (e.g., JSON schemata and the like) and is subject to the normal IPR rules. In this case, there would be no additional workload on OASIS staff. In case we do proceed with option #2, if that is in fact an option, then we should put it to a TC-wide vote and in establishing this CTI Github organization all agree that projects hosted there be subject to licenses amenable to both open source and commercial usage, such as the Apache 2.0 or MIT licenses. Just my two cents... -- Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- "Well, I've been to one world fair, a picnic, and a rodeo, and that's the stupidest thing I ever heard come over a set of earphones. You sure you got today's codes?" --Major T. J. "King" Kong Attachment: signature.asc Description: Digital signature


  • 34.  RE: [cti] Status of CTI OASIS Open Repositories

    Posted 10-11-2016 13:40
    Thanks for the feedback, Trey. > I *thought* we were talking about #2. Bret seems to be talking about #1, which is why I was confused. > The biggest advantage I see is the > ability to deal with issues and pull requests from non-TC members on open > source projects initiated up by TC members. This is possible in OASIS open repositories today. The CLA that open repositories require is similar to that required by other prominent open source projects. > If we're going down the road of hosting things like the STIX 1=>2 upgrade > utility and the STIX Patterning reference implementation, eventually (I > suppose) the next generation of python-stix and libtaxii, then the entire > ecosystem (including the TC membership) stands to gain by making it > straightforward for non-TC members to contribute bug fixes and feature > enhancements to these open source tools. Concur. In what way is this not addressed by the current Open Repositories? > I am *not* including things like JSON schemata and STIX/TAXII issue tracking > in this category. I fully support the stuff that really falls under the rubric of > the standards being subject to the normal IPR rules. I've heard a consensus desire to keep JSON schemas out of work products, and consider them non-normative. If that has changed, we need to re-evaluate having the https://github.com/oasis-open/cti-stix2-json-schemas repo. > > Specifically regarding #2, the strongest argument I've heard is that > > it would help keep the CTI open source repos separate from other TC's, > > even though this can easily be done by searching for "cti-" > > [1]. From a user standpoint, nearly all interaction with GitHub is > > done on a per-repository basis, not per-organization. You can't watch, > > star, or fork an organization, nor I have I seen any way to > > automatically follow new repos that get created in an organization. > > The only exception is the "dashboard" view > > ( https://github.com/orgs/ <ORGNAME>/dashboard), which is only available > > to members of the organization. For Open Repositories, under current > > policies only the maintainers become members of the organization. I > > personally never use the dashboard view for any organizations I am a > > member of. The result is that each repository would need to be handled > > individually, regardless of whether it's in the same organization as > > repositories sponsored by other TCs. > > > > That's your experience, Greg. Mine differs. > > While I do often interact directly with a single Git repository, I also frequently > look at the parent Github org for new and interesting projects or when I > forget the name of a specific project. Fair point. I do this as well. Granted, I spend enough time browsing GitHub that I don't mind non-CTI projects in the same organization at CTI projects (I've found a lot of interesting projects by just browsing random organizations), so my experience may be atypical. > Interested to hear what others have to say. Agreed > > On the other hand, in my experience maintaining multiple organizations > > is significantly more work than maintaining multiple teams within the > > same organization. Since I imagine OASIS staff will be maintaining > > these organizations, I'd like to make it as easy on them as possible. > > > > If OASIS sets up a TC-specific Github organization for supporting open source > tools and libraries, they can delegate the day-to-day maintenance of that to > trusted members of the CTI TC, given that we establish a clear line as to what > falls under the rubric of the standards (e.g., JSON schemata and the like) and > is subject to the normal IPR rules. In this case, there would be no additional > workload on OASIS staff. > > In case we do proceed with option #2, if that is in fact an option, then we > should put it to a TC-wide vote and in establishing this CTI Github > organization all agree that projects hosted there be subject to licenses > amenable to both open source and commercial usage, such as the Apache > 2.0 or MIT licenses. This is exactly what exists today with open repos (day-to-day maintenance trusted to TC members, with licenses amenable to open source and commercial usage). I don’t see a scenario where administrative rights for such an organization would be granted to non-OASIS staff (if so, then a lot of my arguments are moot). Greg


  • 35.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-11-2016 17:14
    We have two fundamentally different needs... 1) A place to keep and track issues against the published specifications.  We are wanting to use the Github issue tracker for this instead of using JIRA.  This is totally independent from the work you are doing Greg.  2) We need a place for opensource projects that are designed to increase adoption of STIX and TAXII to live.  JSON schemas will go here as well because of weird rules in OASIS land with schemas.  Namely, if you produce a schema for an OASIS standard, the schema becomes authoritative and normative.  We want the specifications to be authoritative and the schemas to be just helps. Bret From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Back, Greg <gback@mitre.org> Sent: Tuesday, October 11, 2016 7:40:05 AM To: Trey Darley Cc: cti@lists.oasis-open.org Subject: RE: [cti] Status of CTI OASIS Open Repositories   Thanks for the feedback, Trey. > I *thought* we were talking about #2. Bret seems to be talking about #1, which is why I was confused. > The biggest advantage I see is the > ability to deal with issues and pull requests from non-TC members on open > source projects initiated up by TC members. This is possible in OASIS open repositories today. The CLA that open repositories require is similar to that required by other prominent open source projects. > If we're going down the road of hosting things like the STIX 1=>2 upgrade > utility and the STIX Patterning reference implementation, eventually (I > suppose) the next generation of python-stix and libtaxii, then the entire > ecosystem (including the TC membership) stands to gain by making it > straightforward for non-TC members to contribute bug fixes and feature > enhancements to these open source tools. Concur. In what way is this not addressed by the current Open Repositories? > I am *not* including things like JSON schemata and STIX/TAXII issue tracking > in this category. I fully support the stuff that really falls under the rubric of > the standards being subject to the normal IPR rules. I've heard a consensus desire to keep JSON schemas out of work products, and consider them non-normative. If that has changed, we need to re-evaluate having the https://github.com/oasis-open/cti-stix2-json-schemas repo. > > Specifically regarding #2, the strongest argument I've heard is that > > it would help keep the CTI open source repos separate from other TC's, > > even though this can easily be done by searching for "cti-" > > [1]. From a user standpoint, nearly all interaction with GitHub is > > done on a per-repository basis, not per-organization. You can't watch, > > star, or fork an organization, nor I have I seen any way to > > automatically follow new repos that get created in an organization. > > The only exception is the "dashboard" view > > ( https://github.com/orgs/<ORGNAME>/dashboard ), which is only available > > to members of the organization. For Open Repositories, under current > > policies only the maintainers become members of the organization. I > > personally never use the dashboard view for any organizations I am a > > member of. The result is that each repository would need to be handled > > individually, regardless of whether it's in the same organization as > > repositories sponsored by other TCs. > > > > That's your experience, Greg. Mine differs. > > While I do often interact directly with a single Git repository, I also frequently > look at the parent Github org for new and interesting projects or when I > forget the name of a specific project. Fair point. I do this as well. Granted, I spend enough time browsing GitHub that I don't mind non-CTI projects in the same organization at CTI projects (I've found a lot of interesting projects by just browsing random organizations), so my experience may be atypical. > Interested to hear what others have to say. Agreed > > On the other hand, in my experience maintaining multiple organizations > > is significantly more work than maintaining multiple teams within the > > same organization. Since I imagine OASIS staff will be maintaining > > these organizations, I'd like to make it as easy on them as possible. > > > > If OASIS sets up a TC-specific Github organization for supporting open source > tools and libraries, they can delegate the day-to-day maintenance of that to > trusted members of the CTI TC, given that we establish a clear line as to what > falls under the rubric of the standards (e.g., JSON schemata and the like) and > is subject to the normal IPR rules. In this case, there would be no additional > workload on OASIS staff. > > In case we do proceed with option #2, if that is in fact an option, then we > should put it to a TC-wide vote and in establishing this CTI Github > organization all agree that projects hosted there be subject to licenses > amenable to both open source and commercial usage, such as the Apache > 2.0 or MIT licenses. This is exactly what exists today with open repos (day-to-day maintenance trusted to TC members, with licenses amenable to open source and commercial usage). I don’t see a scenario where administrative rights for such an organization would be granted to non-OASIS staff (if so, then a lot of my arguments are moot). Greg


  • 36.  RE: [cti] Status of CTI OASIS Open Repositories

    Posted 10-11-2016 18:17
    [Consolidating responses to all three messages here] Leaving this issue of TC Work Product repos aside, "OASIS Open Repositories" (perhaps unfortunately named due to the confusion with the oasis-open.org domain that OASIS uses for its entire web presence), are defined in [1] and require a signed CLA [2]. You don't need to be an OASIS member to contribute to the open repositories. I think it is unwise to create an organization on GitHub that accepts contributions without (at least implicitly) requiring contributors to agree to terms similar to the OASIS CLA. If you believe that simply having text that says "by submitting an issue or pull request, you agree that... " is preferred to "formally" signing the OASIS CLA, I think that's a valid issue for the TC to discuss. I find it unlikely that any organization will permit contributions to the organization (which is what I assume you mean by "project") you propose, that would not also permit contributions to the "oasis-open" organization for Open Repository. I'm not an IP lawyer, that's why I defer to what OASIS has established. Greg [1] https://www.oasis-open.org/resources/open-repositories/ [2] https://www.oasis-open.org/resources/open-repositories/cla/individual-cla [UNRELATED TO THE ABOVE] For the record, I personally disagree with the decision to not make the schemas authoritative, but recognize that decision has already been made. >
    Original Message


  • 37.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-11-2016 19:08
    The problems comes in with having to sign a CLA.  That alone makes the cost of entry too high for some people.  This is why I motion that the TC create a project on Github outside of OASIS for all of this.  Then we solve several issues all at once. Bret  Sent from my Commodore 64 PGP Fingerprint:  63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 On Oct 11, 2016, at 12:16 PM, Back, Greg < gback@mitre.org > wrote: [Consolidating responses to all three messages here] Leaving this issue of TC Work Product repos aside, "OASIS Open Repositories" (perhaps unfortunately named due to the confusion with the oasis-open.org domain that OASIS uses for its entire web presence), are defined in [1] and require a signed CLA [2]. You don't need to be an OASIS member to contribute to the open repositories. I think it is unwise to create an organization on GitHub that accepts contributions without (at least implicitly) requiring contributors to agree to terms similar to the OASIS CLA. If you believe that simply having text that says "by submitting an issue or pull request, you agree that... " is preferred to "formally" signing the OASIS CLA, I think that's a valid issue for the TC to discuss. I find it unlikely that any organization will permit contributions to the organization (which is what I assume you mean by "project") you propose, that would not also permit contributions to the "oasis-open" organization for Open Repository. I'm not an IP lawyer, that's why I defer to what OASIS has established. Greg [1] https://www.oasis-open.org/resources/open-repositories/ [2] https://www.oasis-open.org/resources/open-repositories/cla/individual-cla [UNRELATED TO THE ABOVE] For the record, I personally disagree with the decision to not make the schemas authoritative, but recognize that decision has already been made.
    Original Message


  • 38.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-11-2016 19:19
    Having it outside of OASIS does cause some problems with trust. How can a new user know that the code in the repository is trustworthy? A new user is unlikely to contribute to the code when they are still learning about STIX and TAXII. They are more likely to contribute after they have joined the CTI, in which case they will have already signed the IPR agreement. At which point signing a CLA won't cause to much extra consternation. Cheers Terry MacDonald Cosive On 12 Oct. 2016 08:07, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote: The problems comes in with having to sign a CLA.  That alone makes the cost of entry too high for some people.  This is why I motion that the TC create a project on Github outside of OASIS for all of this.  Then we solve several issues all at once. Bret  Sent from my Commodore 64 PGP Fingerprint:  63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 On Oct 11, 2016, at 12:16 PM, Back, Greg < gback@mitre.org > wrote: [Consolidating responses to all three messages here] Leaving this issue of TC Work Product repos aside, "OASIS Open Repositories" (perhaps unfortunately named due to the confusion with the oasis-open.org domain that OASIS uses for its entire web presence), are defined in [1] and require a signed CLA [2]. You don't need to be an OASIS member to contribute to the open repositories. I think it is unwise to create an organization on GitHub that accepts contributions without (at least implicitly) requiring contributors to agree to terms similar to the OASIS CLA. If you believe that simply having text that says "by submitting an issue or pull request, you agree that... " is preferred to "formally" signing the OASIS CLA, I think that's a valid issue for the TC to discuss. I find it unlikely that any organization will permit contributions to the organization (which is what I assume you mean by "project") you propose, that would not also permit contributions to the "oasis-open" organization for Open Repository. I'm not an IP lawyer, that's why I defer to what OASIS has established. Greg [1] https://www.oasis-open.org/ resources/open-repositories/ [2] https://www.oasis-open.org/ resources/open-repositories/ cla/individual-cla [UNRELATED TO THE ABOVE] For the record, I personally disagree with the decision to not make the schemas authoritative, but recognize that decision has already been made.
    Original Message


  • 39.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-11-2016 20:57
    A repo in OASIS does not increase trust. In fact, long term, most of the people that will use STIX and TAXII will never join OASIS.  As Rich S has said and I agree, OASIS CTI membership is about building the standards not the tools and libraries.  Also keep in mind that if the repo is owned by OASIS and you start a project and then 12 months later deprecate it and rewrite it (a common think in open source) with all new functionality you can not delete that old repo that you do not want people to use.  It has to stay around forever, even if it contains code that is wrong. In regards to getting things signed, even if you went through the 3-5 month process to get the paper work signed to join OASIS does not mean it will be easier to get the CLA signed. You will still have that 3-5 month process working with your OGC. Sent from my Commodore 64 PGP Fingerprint:  63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 On Oct 11, 2016, at 1:19 PM, Terry MacDonald < terry.macdonald@cosive.com > wrote: Having it outside of OASIS does cause some problems with trust. How can a new user know that the code in the repository is trustworthy? A new user is unlikely to contribute to the code when they are still learning about STIX and TAXII. They are more likely to contribute after they have joined the CTI, in which case they will have already signed the IPR agreement. At which point signing a CLA won't cause to much extra consternation. Cheers Terry MacDonald Cosive On 12 Oct. 2016 08:07, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote: The problems comes in with having to sign a CLA.  That alone makes the cost of entry too high for some people.  This is why I motion that the TC create a project on Github outside of OASIS for all of this.  Then we solve several issues all at once. Bret  Sent from my Commodore 64 PGP Fingerprint:  63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 On Oct 11, 2016, at 12:16 PM, Back, Greg < gback@mitre.org > wrote: [Consolidating responses to all three messages here] Leaving this issue of TC Work Product repos aside, "OASIS Open Repositories" (perhaps unfortunately named due to the confusion with the oasis-open.org domain that OASIS uses for its entire web presence), are defined in [1] and require a signed CLA [2]. You don't need to be an OASIS member to contribute to the open repositories. I think it is unwise to create an organization on GitHub that accepts contributions without (at least implicitly) requiring contributors to agree to terms similar to the OASIS CLA. If you believe that simply having text that says "by submitting an issue or pull request, you agree that... " is preferred to "formally" signing the OASIS CLA, I think that's a valid issue for the TC to discuss. I find it unlikely that any organization will permit contributions to the organization (which is what I assume you mean by "project") you propose, that would not also permit contributions to the "oasis-open" organization for Open Repository. I'm not an IP lawyer, that's why I defer to what OASIS has established. Greg [1] https://www.oasis-open.org/ resources/open-repositories/ [2] https://www.oasis-open.org/ resources/open-repositories/ cla/individual-cla [UNRELATED TO THE ABOVE] For the record, I personally disagree with the decision to not make the schemas authoritative, but recognize that decision has already been made.
    Original Message


  • 40.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-05-2016 16:06
    Yes, exactly.  I mean I guess the other option is someone could start an opensource project outside of OASIS and we could all just contribute our code there.  This would solve all of these problems.   Bret From: Jason Keirstead <Jason.Keirstead@ca.ibm.com> Sent: Wednesday, October 5, 2016 8:46:16 AM To: Mark Davidson Cc: Robin Cover; Ted Bedwell (tebedwel); Terry MacDonald; Bret Jordan (CS); cti@lists.oasis-open.org; Kirillov, Ivan A.; Back, Greg Subject: Re: [cti] Status of CTI OASIS Open Repositories   The other aspect of this that should be considered by OASIS IMO, and why Mark's plan is very good - is that as these open repositories grow, it is going to quickly become a management headache under the current structure, because it lacks the ability to break things down by TC. Image our TC has 20 repos, another has 10, another has 15... quickly, when one goes to https://github.com/oasis-open/ , they will be confronted with a list of hundreds of repositories... as a user, how do I quickly filter this list to only contain only CTI TC items (or any other TC)? Whereas, if we use Mark's plan, all of the repos for a given TC are in one place, and it is easy as a user to find them on Github. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Mark Davidson ---10/05/2016 10:53:48 AM---Robin, My primary concern is that balloting seems slightly more heavyweight of a process than necess From: Mark Davidson <mdavidson@soltra.com> To: Robin Cover <robin@oasis-open.org> Cc: "Ted Bedwell (tebedwel)" <tebedwel@cisco.com>, Terry MacDonald <terry.macdonald@cosive.com>, "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Jason Keirstead/CanEast/IBM@IBMCA, "Kirillov, Ivan A." <ikirillov@mitre.org>, "Back, Greg" <gback@mitre.org> Date: 10/05/2016 10:53 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: <cti@lists.oasis-open.org> Robin, My primary concern is that balloting seems slightly more heavyweight of a process than necessary for governing the GitHub Repos. To your main point, I do think there is a way to improve the process to a mutually agreeable end state. You raise some good questions, and I’d like to address them directly: > 1. Can you clarify that you make reference to GitHub repos that are used only by TC Members, governed by all OASIS policies (IPR, TC Process...) as opposed to "open" repositories that allow participation by anyone, via CLA, under open source licensing ? I am talking about GitHub repos that are governed by OASIS policies. I am under the impression that these repositories can be used by anyone. > 2. Can you explain why GitHub Project Pages will not work for the TCs? What features of Organization Pages are lacking in Project Pages [1]? There’s two reasons I’d like to consider one GitHub organization or the CTI TC (vs one GitHub org for all things OASIS) First - User, Project, and Organization pages differ in terms of the Hostname/URL that GitHub provides. Personally, I feel pretty strongly that our websites should have names that are short and easy to remember. In my opinion, e.g., https://oasis-open.github.io/cti-documentation just will not stick with people the same way that https://stixproject.github.io sticks with people. There are other ways to achieve this – including a custom domain [1], but we should figure it out IMO. Second – The way people use GitHub, it (IMO) just makes more sense for related repos to be under a single GitHub organization and for unrelated repos to be located somewhere else. I’m interested in what other people think here (I’m just one opinon), but I’m strongly in favor of having one GitHub org for the CTI TC. > 3. Are you proposing that the repos you envision are NOT governed by OASIS rules? My apologies – I picked a bad example (repo deletion). My goal is a better process. In no way do I intend to circumvent or avoid the rules that we all agreed to support by joining OASIS. Thank you. -Mark [1] https://help.github.com/articles/using-a-custom-domain-with-github-pages/ From: Robin Cover <robin@oasis-open.org> Date: Wednesday, October 5, 2016 at 9:04 AM To: Mark Davidson <mdavidson@soltra.com> Cc: "Ted Bedwell (tebedwel)" <tebedwel@cisco.com>, Terry MacDonald <terry.macdonald@cosive.com>, "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "Kirillov, Ivan A." <ikirillov@mitre.org>, "Back, Greg" <gback@mitre.org>, Robin Cover <robin@oasis-open.org> Subject: Re: [cti] Status of CTI OASIS Open Repositories Mark, I'll try to track with the conversation referenced below. We (OASIS) did consider several alternatives when designing the current plans for OASIS Open Repositories and (distinct from) GitHub Repos for TC work. Initially, two questions for you 1. Can you clarify that you make reference to GitHub repos that are used only by TC Members, governed by all OASIS policies (IPR, TC Process...) as opposed to "open" repositories that allow participation by anyone, via CLA, under open source licensing ? 2. Can you explain why GitHub Project Pages will not work for the TCs? What features of Organization Pages are lacking in Project Pages [1]? 3. Are you proposing that the repos you envision are NOT governed by OASIS rules? Foe example, you talk about repo deletion as a desirable feature ("t he operating rules can be superseded by a ballot on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted.." OASIS rules prohibit deletion of resources created by TC members [2] Comment: If you principal concern is about "ballots" (" A set of operating rules for managing repos that does NOT require a ballot"), then I think there is room within OASIS practice (and policy), perhaps with a few clarifications and updates, to allow most of what a TC wants to do -- without ballot. The matter of requiring a ballot for TC creation was raised earlier: under current OASIS rules, a "ballot" is not required for creation of an OASIS Open Repository or for the creation of a TC GitHub repo (repository for TC CHartered work). What's required is meeting minutes. We can clarify that further. That's all for now. Thanks, - Robin [1] https://help.github.com/articles/user-organization-and-project-pages/#project-pages [2] http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#resourcePermanence Resource Permanence As part of the OASIS institutional commitment to transparency, openness, accountability, and public auditability, resources published in the OASIS Library, TC Document Repository, and other venues must not be deleted or otherwise altered. Resources may be revised, but all revisions are retained. With the exception of resources identified by "latest version" URI aliases, content instantiated as regular files and directories must not be over-written, replaced, renamed, or removed. TC Members are expected to follow this rule even in cases where a collaboration tool (by some means) might allow resource deletion or silent alteration. On Wed, Oct 5, 2016 at 7:30 AM, Mark Davidson < mdavidson@soltra.com > wrote: I realize this might go against the grain for some, but maybe we should talk about the organization of GitHub repos on the next working call. Personally, having one OASIS organization for _all_ GitHub repos is going to make tracking the work of any single TC more difficult. In addition, one OASIS organization prevents individual TCs from having *. github.io pages, which the STIX/TAXII group has made good use of in the past. I’d like it if we could consider a method that would provide the necessary governance AND make the management of GitHub repos a little less cumbersome. I don’t know if it’s feasible, but I’d be interested in exploring a structure that has the following properties: · A GitHub organization for the CTI TC (e.g., github.com/oasis-cti-tc/ ) · All CTI TC repos fall under the OASIS-CTI-TC GitHub Org · A set of operating rules for managing repos that does NOT require a ballot. Possible operating rules: o New repos require sponsorship by a co-chair and sign-off by the TC chair o Repo maintainer has some authority over who has which rights o Any part of the operating rules can be superseded by a ballot on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted) · Other considerations? Basically, my goal would be to free us up a bit in terms of repo management, while staying true to the intent of participating in OASIS. What do people think? Thank you. -Mark From: < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org > Date: Tuesday, October 4, 2016 at 7:02 PM To: "Ted Bedwell (tebedwel)" < tebedwel@cisco.com > Cc: Terry MacDonald < terry.macdonald@cosive.com >, "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories Another resource on submodules "Working with submodules" (February 01, 2016) https://github.com/blog/2104-working-with-submodules -rcc On Tue, Oct 4, 2016 at 3:56 PM, Ted Bedwell (tebedwel) < tebedwel@cisco.com > wrote: For the other git neophytes out there: https://git-scm.com/book/en/v2/Git-Tools-Submodules http://blogs.atlassian.com/2013/03/git-submodules-workflows-tips/ This seems like a viable approach. From: < cti@lists.oasis-open.org > on behalf of Terry MacDonald < terry.macdonald@cosive.com > Date: Tuesday, October 4, 2016 at 3:19 PM To: "Bret Jordan (CS)" < Bret_Jordan@symantec.com > Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories Couldn't we do a git repo containing submodules? Then each tool can have its own git repo, and it can be linked a submodules into the overall tools collection repo. This then makes it easy for everyone to get a copy of all three rows from one place, and yet we avoid the problems with many different people who only need access to parts of the git tree... Cheers Terry MacDonald Cosive On 4 Oct. 2016 9:09 am, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote: The problem with all of this is that it is not a collection of repos, but rather specific repos. Including multiple projects in a single repo is considered "bad form". Yes, you can do funky things with TAGS and you can even use different directories in the same repo. But that kind of break the git model. So instead of OASIS creating a oasis-open project with a bunch of arrant TC repos underneath, it seems like OASIS should setup a TC specific "projects". Then the TC can create as many repos on the project that it wants. Bret From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org > Sent: Thursday, September 29, 2016 8:28:43 AM To: Jason Keirstead Cc: Kirillov, Ivan A.; Back, Greg; OASIS CTI TC Discussion List; Robin Cover Subject: Re: [cti] Status of CTI OASIS Open Repositories On Thu, Sep 29, 2016 at 9:14 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: RE " I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" " It is basically tied back to the need, currently, to be a TC member and make a motion if you want to make a new repository OK, I understand. I'll raise the issue with Staff: can/should we support some means whereby a non-TC Member can easily make request for a new OASIS Open Repository where it's perceived that no existing Open Repository repository is suitable. , combined with these repositories being tied to very specific projects and not having a generic top-level repository. In the case at hand: the CTI TC can create an OASIS Open Repository described as "generic": that is your choice. I suppose you could also characterize some new OASIS Open Repository as "top-level" (notionally) if the TC members wanted to do that. Imagine a non-TC member has some brand new code they want to contribute, but it does not fall into any of these existing open repository categories, and we have no "generic" type of repository. They can not make a new repository, or even motion to make one, as they are not a TC member. They're stuck. The only way they could donate this code, would be to try to proxy through another TC member to get the repository created for them to commit it to. I strongly suspect that instead of that hassle they would just put it up on their own Github. Thanks for the clarification via examples. I'll certainly raise the issue with Staff. All such suggestions for improvement are welcome. Kindest regards and best wishes, - Robin - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/29/2016 09:28:30 AM---On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/29/2016 09:28 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I hear what you are saying and there are definitely pros and cons to having some more generic repositories - but I am trying to envision the near future where we will hopefully have a whole bunch of various code contributions from vendors, members and hopefully non-members alike. This is just my opinion of course, but I think we should try to make the process to contribute code to the TC as light-weight as possible, to encourage people to contribute to our open repositories vs. just throw it up on their own Github account - as if they do that, then IPR and access is not as assured. Having to make a motion to create a new repository every time someone wants to contribute some new code, is a fairly heavyweight process in my opinion. It also means that only TC members can contribute any "new things", because the public can't trigger a vote on making a new repository - so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member). Jason, I'll raise the matter of requiring a motion/ballot with Staff. We probably want some kind of confirmation from the TC Chairs(s) -- indicating that there was consensus on the key elements of the request (name, Maintainers, choice of FOSS license, etc) Re: > a whole bunch of various code contributions from vendors, members and hopefully non-members alike That sounds great, and OASIS Open Repositories are intended to support that. It's a TC decision whether you want more or fewer repositories. It's a TC decision as to whether the repos are described as "generic" or having closely defined focus. I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" For the OASIS Open Repositories, once the repo is created, anyone from "the public" (non-TC member) can be a full participant, including Maintainer, per consensus. They can contribute "new things" in the same way as anyone can contribute new things to any GitHub public repository. Perhaps I misunderstand your concern.... I have assumed, maybe incorrectly, that your mention of a new repository (additional to those reported by Greg Back [1]) meant you want a new OASIS Open Repository ( https://www.oasis-open.org/resources/open-repositories ) - Robin [1] cti-stix2-json-schemas cti-pattern-validator cti-marking-prototype cti-stix-visualization cti-stix-validator cti-documentation cti-cybox3-json-schemas - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/28/2016 10:35:01 PM---Jason, The decision about creating something like "stix-tools" is (of course) a From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/28/2016 10:35 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > Jason, The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race. Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository. One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent) design that uses folders within a single repository. Using separate repos means less work (design work, workday-work) when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo. Just use one taxonomy of types/labels without namespace worries. And: you can five write privs to relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects... But as always: it's up to the TC, and I am no expert here. - Robin On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Hello all; IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement. It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets? -- Sent from my mobile device, please excuse any typos. Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories --- From: "Kirillov, Ivan A." < ikirillov@mitre.org > To: "Back, Greg" < gback@mitre.org >, cti@lists.oasis-open.org Date: Wed, Sep 28, 2016 2:09 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-) Regards, Ivan On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org on behalf of Back, Greg" < cti@lists.oasis-open.org on behalf of gback@mitre.org > wrote: >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS. > >- cti-stix2-json-schemas >- cti-pattern-validator >- cti-marking-prototype >- cti-stix-visualization >- cti-stix-validator > >There are two other repositories that exist, but do not (yet) have any content: > >- cti-documentation >- cti-cybox3-json-schemas > >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor License Agreement (CLA): https://www.oasis-open.org/resources/open-repositories/cla . This applies *even to TC members*. > >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions about the process, etc. > >You can find the repositories here: https://github.com/oasis-open > >Thanks, > >Greg Back >MITRE > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > -- -- -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783


  • 41.  Re: [cti] Status of CTI OASIS Open Repositories

    Posted 10-05-2016 15:59
    I completely agree with this..  Having a TC specific repo would make the most sense.  The fact that we can not use github.io pages is also a real pain. Bret From: Mark Davidson <mdavidson@soltra.com> Sent: Wednesday, October 5, 2016 6:30:59 AM To: Robin Cover; Ted Bedwell (tebedwel) Cc: Terry MacDonald; Bret Jordan (CS); cti@lists.oasis-open.org; Jason Keirstead; Kirillov, Ivan A.; Back, Greg Subject: Re: [cti] Status of CTI OASIS Open Repositories   I realize this might go against the grain for some, but maybe we should talk about the organization of GitHub repos on the next working call. Personally, having one OASIS organization for _all_ GitHub repos is going to make tracking the work of any single TC more difficult. In addition, one OASIS organization prevents individual TCs from having *.github.io pages, which the STIX/TAXII group has made good use of in the past. I’d like it if we could consider a method that would provide the necessary governance AND make the management of GitHub repos a little less cumbersome.   I don’t know if it’s feasible, but I’d be interested in exploring a structure that has the following properties: ·          A GitHub organization for the CTI TC (e.g., github.com/oasis-cti-tc/) ·          All CTI TC repos fall under the OASIS-CTI-TC GitHub Org ·          A set of operating rules for managing repos that does NOT require a ballot. Possible operating rules: o     New repos require sponsorship by a co-chair and sign-off by the TC chair o     Repo maintainer has some authority over who has which rights o     Any part of the operating rules can be superseded by a ballot on the topic (e.g., if a maintainer doesn’t want a repo deleted, but the repo really should be deleted) ·          Other considerations?   Basically, my goal would be to free us up a bit in terms of repo management, while staying true to the intent of participating in OASIS. What do people think?   Thank you. -Mark   From: <cti@lists.oasis-open.org> on behalf of Robin Cover <robin@oasis-open.org> Date: Tuesday, October 4, 2016 at 7:02 PM To: "Ted Bedwell (tebedwel)" <tebedwel@cisco.com> Cc: Terry MacDonald <terry.macdonald@cosive.com>, "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "Kirillov, Ivan A." <ikirillov@mitre.org>, "Back, Greg" <gback@mitre.org> Subject: Re: [cti] Status of CTI OASIS Open Repositories   Another resource on submodules   "Working with submodules" (February 01, 2016) https://github.com/blog/2104-working-with-submodules   -rcc   On Tue, Oct 4, 2016 at 3:56 PM, Ted Bedwell (tebedwel) < tebedwel@cisco.com > wrote: For the other git neophytes out there: https://git-scm.com/book/en/v2/Git-Tools-Submodules http://blogs.atlassian.com/2013/03/git-submodules-workflows-tips/   This seems like a viable approach.   From: < cti@lists.oasis-open.org > on behalf of Terry MacDonald < terry.macdonald@cosive.com > Date: Tuesday, October 4, 2016 at 3:19 PM To: "Bret Jordan (CS)" < Bret_Jordan@symantec.com > Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org > Subject: Re: [cti] Status of CTI OASIS Open Repositories   Couldn't we do a git repo containing submodules? Then each tool can have its own git repo, and it can be linked a submodules into the overall tools collection repo. This then makes it easy for everyone to get a copy of all three rows from one place, and yet we avoid the problems with many different people who only need access to parts of the git tree... Cheers Terry MacDonald Cosive   On 4 Oct. 2016 9:09 am, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote: The problem with all of this is that it is not a collection of repos, but rather specific repos.  Including multiple projects in a single repo is considered "bad form".  Yes, you can do funky things with TAGS and you can even use different directories in the same repo.  But that kind of break the git model.  So instead of OASIS creating a oasis-open project with a bunch of arrant TC repos underneath, it seems like OASIS should setup a TC specific "projects".  Then the TC can create as many repos on the project that it wants.   Bret From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Robin Cover < robin@oasis-open.org > Sent: Thursday, September 29, 2016 8:28:43 AM To: Jason Keirstead Cc: Kirillov, Ivan A.; Back, Greg; OASIS CTI TC Discussion List; Robin Cover Subject: Re: [cti] Status of CTI OASIS Open Repositories   On Thu, Sep 29, 2016 at 9:14 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: RE " I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" " It is basically tied back to the need, currently, to be a TC member and make a motion if you want to make a new repository OK, I understand.  I'll raise the issue with Staff: can/should we support some means whereby a non-TC Member can easily make request for a new OASIS Open Repository where it's perceived that no existing Open Repository repository is suitable. , combined with these repositories being tied to very specific projects and not having a generic top-level repository. In the case at hand: the CTI TC can create an OASIS Open Repository described as "generic":  that is your choice.   I suppose you could also characterize some new OASIS Open Repository as "top-level" (notionally) if the TC members wanted to do that.   Imagine a non-TC member has some brand new code they want to contribute, but it does not fall into any of these existing open repository categories, and we have no "generic" type of repository. They can not make a new repository, or even motion to make one, as they are not a TC member. They're stuck. The only way they could donate this code, would be to try to proxy through another TC member to get the repository created for them to commit it to. I strongly suspect that instead of that hassle they would just put it up on their own Github.   Thanks for the clarification via examples.  I'll certainly raise the issue with Staff.  All such suggestions for improvement are welcome.   Kindest regards and best wishes,   - Robin     - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/29/2016 09:28:30 AM---On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/29/2016 09:28 AM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I hear what you are saying and there are definitely pros and cons to having some more generic repositories - but I am trying to envision the near future where we will hopefully have a whole bunch of various code contributions from vendors, members and hopefully non-members alike. This is just my opinion of course, but I think we should try to make the process to contribute code to the TC as light-weight as possible, to encourage people to contribute to our open repositories vs. just throw it up on their own Github account - as if they do that, then IPR and access is not as assured. Having to make a motion to create a new repository every time someone wants to contribute some new code, is a fairly heavyweight process in my opinion. It also means that only TC members can contribute any "new things", because the public can't trigger a vote on making a new repository - so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member). Jason, I'll raise the matter of requiring a motion/ballot with Staff.  We probably want some kind of confirmation from the TC Chairs(s) -- indicating that there was consensus on the key elements of the request (name, Maintainers, choice of FOSS license, etc) Re: > a whole bunch of various code contributions from vendors, members and hopefully non-members alike That sounds great, and OASIS Open Repositories are intended to support that.   It's a TC decision whether you want more or fewer repositories. It's a TC decision as to whether the repos are described as "generic" or having closely defined focus. I don't quite understand your meaning here: "... so the public is basically only able to contribute to things that already exist, not contribute anything new (unless they proxy through a member)" For the OASIS Open Repositories, once the repo is created, anyone from "the public" (non-TC member) can be a full participant, including Maintainer, per consensus.  They can contribute "new things" in the same way as anyone can contribute new things to any GitHub public repository.  Perhaps I misunderstand your concern.... I have assumed, maybe incorrectly, that your mention of a new repository (additional to those reported by Greg Back [1]) meant you want a new OASIS Open Repository (  https://www.oasis-open.org/resources/open-repositories ) - Robin [1] cti-stix2-json-schemas cti-pattern-validator cti-marking-prototype cti-stix-visualization cti-stix-validator cti-documentation cti-cybox3-json-schemas   - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Robin Cover ---09/28/2016 10:35:01 PM---Jason, The decision about creating something like "stix-tools" is (of course) a From: Robin Cover < robin@oasis-open.org > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Kirillov, Ivan A." < ikirillov@mitre.org >, "Back, Greg" < gback@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >, Robin Cover < robin@oasis-open.org > Date: 09/28/2016 10:35 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Sent by: < cti@lists.oasis-open.org > Jason, The decision about creating something like "stix-tools" is (of course) a decision for the TC members, and I have no horse in the race. Some might think "-tools" itself is too broad, and encourage minting a name more specific to the kind of tool (or tools) you want to develop in the repository. One of the OASIS (SSO/SDO) peers has taken a position that specific-purpose GitHub repos works well, as opposed to (an arguably equally competent)  design that uses folders within a single repository.   Using separate repos means less work (design work, workday-work) when creating and applying labels to issues and pull requests: you don't have to permute out name elements that are scoped to the sub-projects within the repo.  Just use one taxonomy of types/labels without namespace worries.  And: you can five write privs to relatively more of the interested parties with fewer discussions about (uh) "who can/should " maintain which sub-projects... But as always: it's up to the TC, and I am no expert here. - Robin On Wed, Sep 28, 2016 at 7:48 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Hello all; IBM has been developing a STIX 2 generator, useful for testing tools. It is rudimentary at this point, but we will continue to improve upon it - and would like to share it with the community for both collaboration and improvement. It doesn't seem to fit into any of these repositories as they are named so specifically. Should we make some more generic one called something like "stix-tools" to cover this and also future potential contributions that would not fit into these buckets? -- Sent from my mobile device, please excuse any typos. Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS Open Repositories --- From: "Kirillov, Ivan A." < ikirillov@mitre.org > To: "Back, Greg" < gback@mitre.org >, cti@lists.oasis-open.org Date: Wed, Sep 28, 2016 2:09 PM Subject: Re: [cti] Status of CTI OASIS Open Repositories Great news! Trey and I hope to begin populating the CybOX 3 JSON schema repo soon :-) Regards, Ivan On 9/28/16, 12:04 PM, " cti@lists.oasis-open.org  on behalf of Back, Greg" < cti@lists.oasis-open.org  on behalf of gback@mitre.org > wrote: >The following OASIS Open repositories have been created and populated with content that MITRE has been developing on behalf of DHS. > >- cti-stix2-json-schemas >- cti-pattern-validator >- cti-marking-prototype >- cti-stix-visualization >- cti-stix-validator > >There are two other repositories that exist, but do not (yet) have any content: > >- cti-documentation >- cti-cybox3-json-schemas > >The open repositories are meant to assist with the development of the TC's work products (but do not contain work products directly). Both TC members and non-members are able to contribute to the repositories, but in order to do so, you must sign a Contributor License Agreement (CLA): https://www.oasis-open.org/resources/open-repositories/cla  . This applies *even to TC members*. > >We welcome participation from other members of the TC (or even non-members who have an interest in the TC's work). Please use GitHub for any issues/enhancement requests for the code/schemas themselves. Feel free to respond to this email if you have questions about the process, etc. > >You can find the repositories here: https://github.com/oasis-open   > >Thanks, > >Greg Back >MITRE > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php   > --     --  


Related Content