OpenC2 leadership –
I think we need to reset the tone of this group.
Bret was not the only person concerned about recent events. But whether he was or not, I don’t believe it is appropriate to single anyone out. I will speak for myself in that, I was asking for time to review and *contribute* further
to the documents being asked for a vote on.
This is a standards body for technology and frankly, we have lost sight (or appears that way) on what we are trying to do.
We want to build a standard that represents a step forward in automated cybersecurity command and control.
It is important that we focus on the technical content of the standard and if people are raising issues about timing or lack of time to provide feedback then the group should be concerned about that.
Not because we are not following process or not. It’s more important the standard matches what we need than whether we followed the exact process.
So these questions on process, points of order….etc are really not helping us.
Quite the opposite. I would say we are not asking questions on the list about a command, what it means, how it should be implemented in a firewall, what’s the difference between mitigate and deny…..etc. Those are important questions.
Questions on process is an indication that we need to get back to the technology.
My request for time to review the 13-page language spec was exactly that. A request to provide further input and help provide further comments if needed. It wasn’t a stall tactic or a process game. But that appears to be the reaction and
the response to my request.
Can we *please* get back to focusing on the technology and building a great standard for *everyone* that is involved.
Allan
From: <openc2@lists.oasis-open.org> on behalf of "duncan@sfractal.com" <duncan@sfractal.com>
Date: Saturday, October 21, 2017 at 2:14 PM
To: Chet Ensign <chet.ensign@oasis-open.org>, "robin@oasis-open.org" <robin@oasis-open.org>, Carol G <carol.geyer@oasis-open.org>
Cc: TC OpenC2 <openc2@lists.oasis-open.org>
Subject: [openc2] Questions on Oasis Process
I'm not sure who to ask so I'll ask all three of you and hope one of you can help me.
I thought I was operating within OASIS process when as SC Chair, we reviewed a document at 3 consecutive subcommittee meetings and submitted it to the TC for CSD
vote. I have been accused us of 'ramrodding' this thru. I thought I was submitting the small subset we'd reached agreement on (draft is 150 pages, CSD proposal is the 13 pages that I thought we had agreement on). In the email below, Bret accuses the subcommittee
meetings of being a 'working call' and 'does not constitute TC wide consensus'.More people were present for SC than he claims but yes it is true less people choose to participate in SC than the full TC. I thought the way to reach TC wide consensus was to bring
the draft to the TC and have the TC vote on the CSD.
Bret and I clearly have different timing objectives. I would like to move as quickly as possible. Bret says "this group is trying to push concepts through far to
quickly". I recognize I'm trying to use agile development processes in what has historically been a waterfall standards process. I personally believe the agile tenants apply in this particular case but I recognize I may be wrong.
Bret proposes we add some more standing rules. I would prefer to work withing the 'normal' OASIS rules and I personally think the OpenC2 standing rules are already
more restrictive than needed and would prefer we not add any more. Because there is some overlap with CTI TC which has a particular way to do things, the CTI get touted as the right way to do things. CTI is one of the very many TC's in OASIS. I would like
to understand how the other TC's in OASIS do things to make a more informed decision.
Could you help provide some perspective on how other TC's operate? How many other TC's have 'Standing rules' that modify the standard OASIS processes? How many
TC's require CSD to be eballoted vs how many allow voting to place at the TC meeting? How many TC's require CSD's to be CS-ready vs how many go thru multiple drafts? What is the distribution of number of CSD revisions prior to becoming a CS? How many TC's
have 'comment periods' prior to voting? What is the distribution on what comment/review period is required? Is there any other data or advice you could provide us to help the TC as a whole as we grapple with the proposed standing rule changes?
iPhone, iTypo, iApologize
-------- Original Message --------
Subject: [openc2] Re: [EXT] [openc2] RE: Workflow change
From: Bret Jordan <Bret_Jordan@symantec.com>
Date: Thu, October 19, 2017 5:26 pm
To: "Brule, Joseph M" <jmbrule@radium.ncsc.mil>
Cc: "openc2@lists.oasis-open.org" <openc2@lists.oasis-open.org>, "Yu,
Sounil" <sounil.yu@bankofamerica.com>
The manner in which you are defending the existing process which I now believe is not what I am suggesting is illustrative that the concerns we have are not being heard.
I feel like this group is trying to push concepts through far to quickly. The fact that last night you mentioned that Allan’s motion is now going to delay us,
is further evident of that.
5-8 people in a working call does not constitute TC wide consensus. Your statements last night that we would resume the up/down vote at the next full TC meeting,
in my belief is yet further proof.
Bret
Sent from my Commodore 128D
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
OpenC2 Technical Committee,
The TC processes that we adopted at our inaugural were designed with the very goals that Mr. Jordan has identified and in fact the current process is very similar to what is proposed here.
The current process (which we have only exercised once) is as follows:
·
We have three subcommittees with very capable co-chairs who are working quite diligently on their respective problem spaces (Language, Actuator and Implementation).
·
The subcommittees to provide updates at every TC meeting and an opportunity is provided for a dialogue at the TC level. This is also an opportunity for the subcommittee to request feedback and help.
·
When the subcommittee reaches general consensus, the entire TC is notified and provided the draft.
·
The subcommittee is expected to provide a recommendation, a minority report (if applicable) and document the gist of any dialogue that took place.
·
The TC is asked to review the document. At this point, the TC is asked to either accept, reject or send it back to the subcommittee for further work and deliberations.
The main distinction between the current and the proposed is that the proposed process suggests that items such as the number and length of the comment periods
and the mechanism for casting the vote is codified.
I am certainly in general agreement and open for discussion regarding matters such as definition of minimal comment periods and the like.
I would like to see us adopt a slightly different process for work in this TC.
I would be in favor of making sure more of the TC as a whole is involved and understands the work that is being done in a SC, since the TC, not the SC, is the group
that actually votes on documents.
I would like to see us adopt a process of.
1) The SC works on content or a document until they think it is done and ready for prime time
2) At this point the SC would inform the broader TC that they have a document that they would like the broader TC to review.
3) A two to three comment period would be opened up for the whole TC to review and comment.
4) The SC will take the comments and feedback and rework the document. This process would then rinse and repeat until there is no more substantive comments in the
document.
5) Once all substantive comments are resolved, then an electronic ballot would be opened to give people one last two week period to review before they vote.
I would like to make sure we are more inclusive and that we try harder to get more people to review it. Having 5-8 people review it in working calls is NOT equal
to TC consensus. Further, doing a simple up/down vote on a full call without ample time to review is a keen to trying to ram rod the standard through the process.
Sent from my Commodore 128D
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
--------------------------------------------------------------------- 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