OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

openc2 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: Questions on Oasis Process

Hi Duncan + members of the OpenC2 TC, 

First, my apologies for replaying to this late on Friday. I was out most of the week and you know what digging out is like when you get back from something like that. I wanted to be able to take the time to give you all solid, helpful answers. 

As you posed specific questions (thank you for that) I will intersperse my replies into your text below. 

On Sat, Oct 21, 2017 at 5:14 PM, <duncan@sfractal.com> wrote:
Chet, Robin, Carol,
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

CE: This far, you are correct. A SC cannot approve a piece of work other than to submit it back to the TC. The SC's purpose is to prepare the material it was requested to create and then present it back to the TC for action. 

for CSD vote.

CE: So here we go a bit off the process rails. The *action* to be taken is up to the TC to decide. The SC can certainly present the work with the suggestion that it is ready for a vote. But the decision about whether or not to immediately start a vote or first spend time reviewing is up to the TC to make. See the TC Process at https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26#subcommittees where it reads "The deliverables of the SC are made only to the TC for such further action as the TC may elect." 
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.

CE: I agree with Bret that "5-8 people in a working call does not constitute TC wide consensus." The benefit of SCs as they are designed is that a sub-group of people can focus on the subject at hand and make quick progress. They are however not the TC as a whole and that's why the rules specify that it is the TC's decision on what to do once the work is passed to them.  

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.

CE: I don't have any observation here other than to note that it does appear you have different objectives but how best to approach that is up to the TC to decide.  

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.

CE: Certainly and let me provide context to the specific questions below.  

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?

CE: I think that there are only 3 or 4 TCs with standing rules. I have not really looked. The PKCS 11 TC adopted a standing rule on how they will manage identifier allocation (a very specialized case) that you can find at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=pkcs11#standing-rules. The Open Document Format (ODF) TC adopted a standing rule to address some procedural issues at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office#other. But I don't believe there are many. 

Note also that standing rules can address areas that the OASIS rules do not and they can place further constraints if need be but they cannot change the OASIS rules.  

How many TC's require CSD to be eballoted vs how many allow voting to place at the TC meeting?

CE: Also not scientific but my sense is that the majority of TCs choose whichever is convenient. If they are going to be meeting and there is a consensus that the working draft is ready to advance, the TC will approve it as a resolution in the meeting. If there is not an upcoming meeting, they'll go ahead and hold the ballot. I do not know of any that *require* electronic ballots. 
How many TC's require CSD's to be CS-ready vs how many go thru multiple drafts?

CE: I am not entirely sure what you mean by "CS-ready." I would say that the majority of TCs try to get their working drafts as close to CS-ready as they can before they put it out for public review. On the question of how many TCs have work products go through multiple drafts before approval as a CS, that is the norm. Almost every working draft from every TC - particularly for new TCs working on their first specifications - go through at least 2 rounds of review and 3 is not uncommon. There are also some TCs that have approved multiple Committee Spec Drafts before sending out their first public review. See as an example TOSCA at http://docs.oasis-open.org/tosca/TOSCA/v1.0/. They approved 5 Committee Spec Drafts before going to public review. 
What is the distribution of number of CSD revisions prior to becoming a CS?

CE: this completely depends on the TC, the complexity of the work, etc. but in general almost every spec draft goes through 2 to 3 CSDs before the TC approves it as a CS. 
How many TC's have 'comment periods' prior to voting?

CE: I assume that here you mean 'how many have inter-TC comment periods on the work submitted by the SC before voting to approve as a CSD?' I think the answer is "most." I can point you to two TCs off the top of my head that follow a rigorous process: Emergency Management (https://lists.oasis-open.org/archives/emergency/) and DITA (https://lists.oasis-open.org/archives/dita/). 

If you look at some of their minutes, you see that they have reports from their SCs at every meeting. When a SC returns a package of work to the TC, they arrange for review and discussion before putting it forward to a vote. My experience with them is that they do not put up a draft from a SC for a vote until the TC has had time to review it, ask questions, and possibly make changes.
What is the distribution on what comment/review period is required?

CE: I assume that you mean review period for the TC after the SC submits its work. Again, it is the TC's decision. There is no requirement other than the section from Subcommittee rules I quoted above. 
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?

CE: Personally, I do not see the need for standing rules as I think the existing rules spell things out sufficiently. The SC presents its work back to the TC and then the TC decides how to proceed from there. 

If members of the TC feel the need to provide more procedural rules, I suggest looking at what the ODF TC (link above) did. They documented, in a standing rule, the protocol by which I member could advance a proposed change or addition to the standard in quite a bit of detail. I have no idea how long it took to do that but I will point out that the language is quite detailed and precise. 

I'll also note that the other TCs I've mentioned - Emergency Management, DITA plus UBL which I didn't but is another good example - worked all this out without adopting standing rules. They came to agreement on how to handle their work and followed those practices. I feel confident OpenC2 can reach consensus without the need for specific standing rules. Also, not that I expect it would be a problem, but standing rules have to be reviewed by TC Admin as well. 

Lastly, I'd just like to echo what Allan said in his reply. The important questions are the ones about the technology; don't get bogged down in process. A big part of the reason that we made the OASIS process lightweight is to let all of you focus on the value you bring to the table. I am sure that you are all doing your best to address what is, frankly, becoming a crisis. I'm sure you can all work successfully to make that happen. 

Well, I have taken far too much of your time but I hope this has been helpful. If anyone on the TC has questions or concerns, please don't hesitate to get in touch with me. It is my job to help you be successful. 

And I really hope you are because my plan B is to move to the upper peninsula of Michigan, go back to desktop dial phones and drive a 1983 Chevy Suburban - that last car manufactured with no computer. I would like to avoid that if at all possible.



Duncan Sparrell
sFractal Consulting LLC
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.


Sent from my Commodore 128D

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

On Oct 19, 2017, at 3:30 PM, Brule, Joseph M <jmbrule@radium.ncsc.mil> wrote:

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.    
Very Respectfully,
Joe Brule
From: openc2@lists.oasis-open.org [mailto:openc2@lists.oasis-open.org] On Behalf Of Bret Jordan
Sent: Thursday, October 19, 2017 3:03 PM
To: openc2@lists.oasis-open.org
Subject: [Non-DoD Source] [openc2] Workflow change
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


Chet Ensign
Director of Standards Development and TC Administration 
OASIS: Advancing open standards for the information society

Primary: +1 973-996-2298
Mobile: +1 201-341-1393 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]