[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Motion for Open Repository for CTI Interop Issue Tracking
> "we do *not* have unanimous consent for opening ‘a’ repo" Is it safe to say that there is no objection in principle to the concepts of having repo, but the issue is which type (github//oasis-open vs github//oasis-tcs)? I've been wrestling with a similar issue in OpenC2 with a similar "can't win" (ie either non-OASIS can't play; or certain OASIS-members can't play). If we have to break the tie, I would tend towards favoring OASIS members (ie the github//oasis-tcs solution). Would it be possible to have both? I think there would be two ways to do this. Method A: github//oasis-tcs is the 'main' repo and the 'definitive' repo github//oasis-open is 'supplemental' In this scenario, members would contribute to github//oasis-tcs and non-members would contribute to github//oasis-open. Note both are world-readable (so both are open wrt readable). Any member so inclined could copy github//oasis-open info to their own fork and then contribute it to github//oasis-tcs. I recognize some legal teams might not approve their employees doing such but I'm assuming since they have the same opensource licenses and the same contributor agreements that someone might be able to do it (only takes one). If no one does it then you have to look in two places which might not be that big a deal if directory structures and cross links are put in between the two (ie if you go into the 'non-OASIS-member' subdir it just is a hotlink to the other repo (and vice versa). Method B: same methodology but reverse which one is 'main/definitive'. I'd favor A over B and I'd really prefer there was just one - but not obvious to me how "one" can be made to work for everyone. Duncan Sparrell sFractal Consulting LLC iPhone, iTypo, iApologize -------- Original Message -------- Subject: [cti] Re: [cti-interoperability] Re: [cti] Re: [EXT] [cti-interoperability] Motion for Open Repository for CTI Interop Issue Tracking From: Allan Thomson <athomson@lookingglasscyber.com> Date: Thu, May 24, 2018 10:32 am To: Robin Cover <robin@oasis-open.org> Cc: John-Mark Gurney <jmg@newcontext.com>, "Back, Greg" <gback@mitre.org>, Bret Jordan <Bret_Jordan@symantec.com>, OASIS CTI TC list <cti@lists.oasis-open.org>, Interoperability Subcommittee <cti-interoperability@lists.oasis-open.org> Given that we have different opinions on whether this should be an open repo vs tc repo we do *not* have unanimous consent for opening ‘a’ repo. I will hold off submitting any request until we have a clear decision on what kind of repo it needs to be. Allan From: "robin@oasis-open.org" <robin@oasis-open.org> Date: Thursday, May 24, 2018 at 7:02 AM To: Allan Thomson <athomson@lookingglasscyber.com> Cc: John-Mark Gurney <jmg@newcontext.com>, "Back, Greg" <gback@mitre.org>, Bret Jordan <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Interoperability Subcommittee <cti-interoperability@lists.oasis-open.org> Subject: Re: [cti-interoperability] Re: [cti] Re: [EXT] [cti-interoperability] Motion for Open Repository for CTI Interop Issue Tracking On Allan's draft proposal/motion to create a new public GitHub repository [3], I've tracked with comments from the TC members (Bret, John-Mark, Greg, Jason, Jane) and sense that the TC has a good understanding of the trade-offs between an OAIS TC Open Repository (open source licensing, anyone can contribute) versus a GitHub repository (primarily) for CTI TC members' use. I have written commentary on the key differences [1] So I reported to Allan Thomson (and Richard Struse) that we will create a public GitHub repo of either type (or more than one new repositry, if warranted), with the claim that "they both can work just fine", given that we configure the GitHub repos with Issues turned on, etc A couple additional thoughts to perhaps help lower the stakes 1) We use stock (boilerplate) language in the README and CONTRIBUTING startup files, but in a case like this, we are happy to supplement the text -- with your recommendations -- to make clear for users and potential users what the goals/purposes are, and whak kinds of contributions are anticipated, and how anyone can "participate" within the expectations. Allan's draft purpose statement ("A CTI-Interoperability issue tracking repository") can be expanded to clarify further.. 2) While we use words like "code" and "contribute" and "participate" in our rules and startup files -- sometimes following GitHub's definitions, which are not entirely precise or consistent, we acknowledge that the repository Maintainers will always need to exercise some judgment about whether and how to use content that is expressed in a GitHub Issue, Pull Request, Comment, Gist, Wiki page (etc) -- since indeed anyone with a GitHub account can create and link to such content. Most content that everyone recognizes as "code" can be expressed in any of the above-mentioned ways. While some organizations have attempted to support clear binary distinction between "code" and non-code" [2], we don't try, because the definitions are too difficult to formulate and applications too difficult to enforce. People mean different things by: (repository "Code"), "contributions", "substantive contributions", "code commits", "editorial changes"... 3) I'm happy to discuss (maybe best on a phone call, if needed, and Chet Ensign could join) some other considerations, but would encourage adoption of the hypothesis that either repo type might work OK, with constraints that are common to all public open source projects, at OASIS and elsewhere, requiring that some kinds of input merit formal declaration of the user's agreement (e.g., in a CLA) and other kinds of "non-substantive, editorial" content changes do not. Every open source project I have seen faces these same challenges. Viz., - Robin [1] OASIS TC Open (Source) Repositories versus Repositories for TC Members' Chartered Work https://tinyurl.com/ydyjd3xz [2] "code" versys not-code (one example) Code Components which may be found in IETF Contributions and IETF Documents http://trustee.ietf.org/license-info/Code-Components-List-4-23-09.txt IESG Statement on Copyright https://www.ietf.org/iesg/statement/copyright.html In addition to the code component types listed, any text found between the markers <CODE BEGINS> and <CODE ENDS> shall be considered a code component. Authors may wish to use these markers as clear delimiters of code components. [3] "Motion for Open Repository for CTI Interop Issue Tracking" (with duplicates) https://lists.oasis-open.org/archives/cti/201805/msg00041.html https://lists.oasis-open.org/archives/cti/201805/msg00042.html https://lists.oasis-open.org/archives/cti/201805/msg00049.html https://lists.oasis-open.org/archives/cti/201805/msg00050.html https://lists.oasis-open.org/archives/cti/201805/msg00051.html https://lists.oasis-open.org/archives/cti/201805/msg00052.html https://lists.oasis-open.org/archives/cti/201805/msg00053.html https://lists.oasis-open.org/archives/cti/201805/msg00054.html\https://lists.oasis-open.org/archives/cti/201805/msg00055.html https://lists.oasis-open.org/archives/cti-interoperability/201805/msg00005.html https://lists.oasis-open.org/archives/cti-interoperability/201805/msg00006.html https://lists.oasis-open.org/archives/cti-interoperability/201805/msg00007.html https://lists.oasis-open.org/archives/cti-interoperability/201805/msg00008.html https://lists.oasis-open.org/archives/cti-interoperability/201805/msg00009.html https://lists.oasis-open.org/archives/cti-interoperability/201805/msg00010.html https://lists.oasis-open.org/archives/cti-interoperability/201805/msg00011.html https://lists.oasis-open.org/archives/cti-interoperability/201805/msg00012.html On Wed, May 23, 2018 at 7:21 PM, Allan Thomson <athomson@lookingglasscyber.com> wrote: John-Mark - As I shared with Greg privately and sharing for the group. STIXPreferred is a certification program intended to be open to non-TC members and TC-members alike. So although the interop test documents are work products of the TC, they will be used by the non-TC members to certify their products. We want feedback on that program as a whole and using the open repo to track issues is one possibility. Secondly, test programs and test data used in future interop tests will be available via this repo (hopefully) and again it would be good to have the option of non-TC members contributing updates/fixes to that data the repo holds. There might be other STIXPreferred content we want to publish and get feedback on via the repo that would suggest an open policy is better. I said to Greg that on balance I understand the issue around IPR for interop contributions vs non-member contributions to help the certification program prosper. My preference is to keep the repo open as I think the likelihood of IPR being an issue for interoperability is low (not zero but low). If someone submits content that will likely cause IPR conflicts then I suggest we would deal with that when it happens. If others think that this will cause a significant problem with IPR conflicts then please speak up. Allan Thomson CTO (+1-408-331-6646) LookingGlass Cyber Solutions <http://www.lookingglasscyber.com/> On 5/23/18, 5:05 PM, "John-Mark Gurney" <jmg@newcontext.com> wrote: Back, Greg wrote this message on Wed, May 23, 2018 at 21:58 +0000: > I’m fine with either, but I’ll point out that a motion to create an open repo is very different from a motion to create a TC repo. Based on what Allan is saying in the purpose statement, it’s probably more suitable as a TC repo [1], using this form [2]. Again, I would be in support of either one, though. If there is no code in the repo, then I'm fine w/ an Open repo. If there will be "code" (i.e. contents in git), then I will agree w/ this should be a TC repo instead. Due to how our business agreements are structured, I cannot contribute "code" to an open repo. I do read this as I'm fine contributing to issues of an open repo. Isn't there a document that people who provide feed back via the public comment period have to sign when submitting responses? Sounds like that could help in this situation. > On 2018-05-22, 20:07, "cti@lists.oasis-open.org<mailto:cti@lists.oasis-open.org> on behalf of Bret Jordan" <cti@lists.oasis-open.org<mailto:cti@lists.oasis-open.org> on behalf of Bret_Jordan@symantec.com<mailto:Bret_Jordan@symantec.com>> wrote: > > > I second this, however, I would suggest the name just be cti-interop this way as an official work product repo, we could use it for other interop related things. Yes, obviously, it will have an issue tracker, but we could do other things with it as well. > > > > Bret > > ________________________________ > From: cti-interoperability@lists.oasis-open.org <cti-interoperability@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com> > Sent: Tuesday, May 22, 2018 4:45:42 PM > To: OASIS CTI TC list > Cc: Interoperability Subcommittee > Subject: [EXT] [cti-interoperability] Motion for Open Repository for CTI Interop Issue Tracking > > > I move that the TC approve by unanimous consent requesting OASIS to set up an OASIS Open Repository named cti-interop-issues using the following pieces of information: > > > > * Purpose Statement: A CTI-Interoperability issue tracking repository > > * Initial Maintainers: Allan Thomson, Jason Keirstead > > * Open Source License: BSD-3-Clause License > > * GitHub Name: cti-interop-issues > > * Short Description: OASIS Open Repository: CTI-Interop Issue Tracking > > > > If there have been no objections by Friday, 25th May, 8am PST, I will submit the form [1] to request OASIS staff to create the repository. > > > > [1]: https://clicktime.symantec.com/a/1/O_ihu1E08Xl2-dCkw-ASiK6V6aRPMzaHPgA8JWCVguA=?d=uExWX7fZn2Kl6plF49kKe_LZP8lrMkLtXgjcy41DR0Fu0FSDcexzZAqC2nn1IMYh1vZ5FISBNpMlibp8Q0YGdjpkIAvhfVRjM1dsDF7cV4gT9qa8h0OjnyVkwC9MH38YSKD2lIHqyY8rhnZXjDuzWpBtp-VTHGRkjFV0W281F9vYddlnNEAE25ie-1Nhr0af-1LmnMK3x4VacBd2yc3UUhapIM5Pqqb-yRWtSq1ZVe0EGfmckl5y8-UwGLKOPkChB785CerSuPcODwZCi8FkAo5apC1IyU_dwL9khyfWaWdeH9AkaMHufWKd5VmISpiqqD5sPRcc9KLHxJQ_oIEHIjQQjQRnSPNRM6xRsDeD8nYOLsbdk6iZwtmXnnNOsf4riJlDR8Bh2-ZNEkQF5Kbql5CIO0Bj-vXyUHnKYHCAjWuD7fSaz6YXLfHN71fJx4whN1cAV3AA_F8MAUW8uP9AXd6s3VH576SP6yheifXsvXSPrvmnnX2t1VHrp2KdF36FZzPIqViSYyR4Mk5GEw%3D%3D&u=https%3A%2F%2Fwww.oasis-open.org%2Fresources%2Ftc-admin-requests%2Fopen-repository-request > > > > Allan -- John-Mark -- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]