[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: GitHub Repos and Organizations (was: RE: [cti] Status of CTI OASIS Open Repositories)
As far as I know, there is nothing keeping someone from creating their own repo outside of OASIS channels for content related to the TC's work.
We (MITRE and DHS) chose to use OASIS open repositories in the hope that it would make others more willing to contribute to the work that we've been doing. Other organizations are of course free to make different decisions.
It's possible that OASIS open repositories will seem "more official", but to the best of my knowledge the only actual distinction is that the former were "approved" by the TC and "maintained" by a TC member (the maintainer doesn't *need* to be a TC member, but I imagine in practice will usually be). I expect that the OASIS Staff, with admin rights to the "oasis-open" organization, will be responsive to decisions made by the TC (via ballots or approved during TC meetings) regarding the open repositories. But is important to distinguish the open repos from TC work products, to not include work products in the open repos (since there are different IPR considerations for each, among other policy concerns), and to combat any perception that the *content* in the open repos is supported by the TC in the same way that work products are.
In serving as the maintainer of many of the open repos, my intent is to take burden off of the Chair and Co-Chairs, not to override decisions. Any decisions a maintainer could make do not impact TC work products. The TC can obviously add, remove, or change maintainers by ballot or during TC meetings, though I believe the intent is to not require that level of formality.
In terms of URLs, it's easy to set up https://cti-tc.github.io/ to point to https://oasis-open.github.io/cti-documentation). In fact, it already does (but there's no content at the latter URL, yet).
> -----Original Message-----
> From: Bret Jordan (CS) [mailto:Bret_Jordan@symantec.com]
> Sent: Wednesday, October 05, 2016 11:05 AM
> To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Mark Davidson
> <mdavidson@soltra.com>
> Cc: Robin Cover <robin@oasis-open.org>; Ted Bedwell (tebedwel)
> <tebedwel@cisco.com>; Terry MacDonald <terry.macdonald@cosive.com>;
> cti@lists.oasis-open.org; Kirillov, Ivan A. <ikirillov@mitre.org>; Back, Greg
> <gback@mitre.org>
> Subject: Re: [cti] Status of CTI OASIS Open Repositories
>
> 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 ("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.." 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 <https://help.github.com/articles/user-organization-
> and-project-pages/#project-pages>
>
>
> [2] http://docs.oasis-
> open.org/specGuidelines/ndr/namingDirectives.html#resourcePermanence
> <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
> <mailto: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
> <http://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/
> <http://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 <mailto:cti@lists.oasis-open.org> > on behalf
> of Robin Cover <robin@oasis-open.org <mailto:robin@oasis-open.org> >
> Date: Tuesday, October 4, 2016 at 7:02 PM
> To: "Ted Bedwell (tebedwel)" <tebedwel@cisco.com
> <mailto:tebedwel@cisco.com> >
> Cc: Terry MacDonald <terry.macdonald@cosive.com
> <mailto:terry.macdonald@cosive.com> >, "Bret Jordan (CS)"
> <Bret_Jordan@symantec.com <mailto:Bret_Jordan@symantec.com> >,
> "cti@lists.oasis-open.org <mailto:cti@lists.oasis-open.org> " <cti@lists.oasis-
> open.org <mailto:cti@lists.oasis-open.org> >, Jason Keirstead
> <Jason.Keirstead@ca.ibm.com <mailto:Jason.Keirstead@ca.ibm.com> >,
> "Kirillov, Ivan A." <ikirillov@mitre.org <mailto:ikirillov@mitre.org> >, "Back,
> Greg" <gback@mitre.org <mailto: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
> <https://github.com/blog/2104-working-with-submodules>
>
> -rcc
>
> On Tue, Oct 4, 2016 at 3:56 PM, Ted Bedwell (tebedwel)
> <tebedwel@cisco.com <mailto:tebedwel@cisco.com> > wrote:
>
> For the other git neophytes out there:
> https://git-scm.com/book/en/v2/Git-Tools-Submodules <https://git-
> scm.com/book/en/v2/Git-Tools-Submodules>
> http://blogs.atlassian.com/2013/03/git-submodules-workflows-tips/
> <http://blogs.atlassian.com/2013/03/git-submodules-workflows-tips/>
>
> This seems like a viable approach.
>
> From: <cti@lists.oasis-open.org <mailto:cti@lists.oasis-open.org> >
> on behalf of Terry MacDonald <terry.macdonald@cosive.com
> <mailto:terry.macdonald@cosive.com> >
> Date: Tuesday, October 4, 2016 at 3:19 PM
> To: "Bret Jordan (CS)" <Bret_Jordan@symantec.com
> <mailto:Bret_Jordan@symantec.com> >
> Cc: "cti@lists.oasis-open.org <mailto:cti@lists.oasis-open.org> "
> <cti@lists.oasis-open.org <mailto:cti@lists.oasis-open.org> >, Robin Cover
> <robin@oasis-open.org <mailto:robin@oasis-open.org> >, Jason Keirstead
> <Jason.Keirstead@ca.ibm.com <mailto:Jason.Keirstead@ca.ibm.com> >,
> "Kirillov, Ivan A." <ikirillov@mitre.org <mailto:ikirillov@mitre.org> >, "Back,
> Greg" <gback@mitre.org <mailto: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 <mailto: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 <mailto:cti@lists.oasis-open.org>
> <cti@lists.oasis-open.org <mailto:cti@lists.oasis-open.org> > on behalf of
> Robin Cover <robin@oasis-open.org <mailto: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 <mailto: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 <http://www.ibm.com/security> |
> www.securityintelligence.com <http://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
> <mailto:Jason.Keirstead@ca.ibm.com> > wrote:
>
> From: Robin Cover <robin@oasis-open.org <mailto:robin@oasis-
> open.org> >
> To: Jason Keirstead/CanEast/IBM@IBMCA
> Cc: "Kirillov, Ivan A." <ikirillov@mitre.org <mailto:ikirillov@mitre.org>
> >, "Back, Greg" <gback@mitre.org <mailto:gback@mitre.org> >, OASIS CTI TC
> Discussion List <cti@lists.oasis-open.org <mailto:cti@lists.oasis-open.org> >,
> Robin Cover <robin@oasis-open.org <mailto: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 <mailto:cti@lists.oasis-open.org>
> >
>
> ________________________________
>
>
>
>
>
> On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead
> <Jason.Keirstead@ca.ibm.com <mailto: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 <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
> <http://www.ibm.com/security> | www.securityintelligence.com
> <http://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
> <mailto:robin@oasis-open.org> >
> To: Jason Keirstead/CanEast/IBM@IBMCA
> Cc: "Kirillov, Ivan A." <ikirillov@mitre.org
> <mailto:ikirillov@mitre.org> >, "Back, Greg" <gback@mitre.org
> <mailto:gback@mitre.org> >, OASIS CTI TC Discussion List <cti@lists.oasis-
> open.org <mailto:cti@lists.oasis-open.org> >, Robin Cover <robin@oasis-
> open.org <mailto: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
> <mailto: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 <mailto: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 <mailto:ikirillov@mitre.org> >
>
>
>
> To:
>
>
>
> "Back, Greg"
> <gback@mitre.org <mailto:gback@mitre.org> >, cti@lists.oasis-open.org
> <mailto: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 <mailto:cti@lists.oasis-open.org> on behalf of
> Back, Greg" <cti@lists.oasis-open.org <mailto:cti@lists.oasis-open.org> on
> behalf of gback@mitre.org <mailto: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 <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 <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
> <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 <mailto:robin@oasis-open.org> Staff bio:
> http://www.oasis-open.org/people/staff/robin-cover <http://www.oasis-
> open.org/people/staff/robin-cover>
> Cover Pages: http://xml.coverpages.org/ <http://xml.coverpages.org/>
> Newsletter: http://xml.coverpages.org/newsletterArchive.html
> <http://xml.coverpages.org/newsletterArchive.html>
> Tel: +1 972-296-1783
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]