cti message

Cc:

Date:

Subject:

Sent by:

https://oasis-open.github.io/cti-documentation

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.,

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 <

Date:

Wednesday, October 5, 2016 at 9:04 AM

To:

Mark Davidson <

mdavidson@soltra.com

Cc:

"Ted Bedwell (tebedwel)" <

>, Terry MacDonald <

>, "Bret Jordan (CS)" <

>, "

" <

>, Jason Keirstead <

>, "Kirillov, Ivan A." <

>, "Back, Greg" <

>, Robin Cover <

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

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]

[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:

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:

> on behalf of Robin Cover <

Date:

Tuesday, October 4, 2016 at 7:02 PM

To:

"Ted Bedwell (tebedwel)" <

Cc:

Terry MacDonald <

>, "Bret Jordan (CS)" <

>, "

" <

>, Jason Keirstead <

>, "Kirillov, Ivan A." <

>, "Back, Greg" <

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

Subject:

Re: [cti] Status of CTI OASIS Open Repositories

Another resource on submodules

"Working with submodules" (February 01, 2016)

-rcc

On Tue, Oct 4, 2016 at 3:56 PM, Ted Bedwell (tebedwel) <

https://git-scm.com/book/en/v2/Git-Tools-Submodules

> wrote:

For the other git neophytes out there:

http://blogs.atlassian.com/2013/03/git-submodules-workflows-tips/

This seems like a viable approach.

From:

> on behalf of Terry MacDonald <

Date:

Tuesday, October 4, 2016 at 3:19 PM

To:

"Bret Jordan (CS)" <

Cc:

" <

>, Robin Cover <

>, Jason Keirstead <

>, "Kirillov, Ivan A." <

>, "Back, Greg" <

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:

> on behalf of Robin Cover <

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 <

www.securityintelligence.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

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 <

> wrote:

From:

Robin Cover <

To:

Jason Keirstead/CanEast/IBM@IBMCA

Cc:

"Kirillov, Ivan A." <

>, "Back, Greg" <

>, OASIS CTI TC Discussion List <

>, Robin Cover <

Date:

09/29/2016 09:28 AM

Subject:

Re: [cti] Status of CTI OASIS Open Repositories

Sent by:

On Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead <

https://www.oasis-open.org/resources/open-repositories

> 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 (

)

- 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 <

To:

Jason Keirstead/CanEast/IBM@IBMCA

Cc:

"Kirillov, Ivan A." <

>, "Back, Greg" <

>, OASIS CTI TC Discussion List <

>, Robin Cover <

Date:

09/28/2016 10:35 PM

Subject:

Re: [cti] Status of CTI OASIS Open Repositories

Sent by:

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 <

> 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, "

on behalf of Back, Greg" <

on behalf of

https://www.oasis-open.org/resources/open-repositories/cla

> 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):

. 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: