Joe, Dave,
We can agree to disagree on workload. My opinion is still the IC-SC has more work than the AP-SC based on the documents in preparation. I agree there were more specific action
items against the SLPF than against the other specs. I agree there should be eventually be more Actuator Profiles than transport specs â but that is not the case at the moment. And the IC-SC is also responsible for the open source â of which there is a growing
amount â as well as information assurance committee note.
But itâs a moot point - all three SCâs said they have work, and more work than people. The meeting notes reflect this.
- IC-SC âMr. Lemire replied that there are certainly work items for the near term, but he remained concerned about
the very low level of participation to address those itemsâ
- AP-SC âmore work items than contributorsâ
- LSC âwas similar to that for the other two SCs: there is work to do, and he is concerned about the small number
of participants to address itâ
But as Toby pointed out, this is generally the case in standards. Everybody wants the answers, but everyone is busy so canât contribute as-much/as-fast as weâd all prefer.
I do not believe regorganizing the TC will change this. I agree with Joeâs assessment that weâd be better off putting the time into writing specs.
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at http://vsre.info/
From: Joseph Brule <jmbrule@radium.ncsc.mil>
Date: Tuesday, February 25, 2020 at 10:39 AM
To: Dave Lemire <dave.lemire@g2-inc.com>, "duncan@sfractal.com" <duncan@sfractal.com>
Cc: TC OpenC2 <openc2@lists.oasis-open.org>
Subject: RE: [Non-DoD Source] Re: [openc2] Subcommittee Reorganization - common meeting
Duncan,
A comment to your comment regarding ârelative work loadsâ I clearly stated âInspection of the number and scope of the action items from the plug fest validates
the hypothesis.â, the bulk of the issues raised at the plug fest were AP-SC related, at least based on the last time I looked at the github issuesâ Still, it is a hypothesis and I did not intend to present it as a fact or âphysical law.â
Dave L,
Your assessment of the relative workloads is similar to what I have guessed and when you think about it, it is logical and consistent with what Sudeep said in
yesterdayâs email:
Sudeep said âLanguage specs are meant to be rigid and comprehensive. Implementations are given to experimentation, fast moving tech landscape and are fluid
by nature. The mechanics of the two are entirely differentâ
Sudeep did not say this, but I will add âThe actuator profiles will also be fast moving and fluid by nature due to the dynamics of technologyâ
My only (very minor) departure from Sudeepâs analysis is that I think in the end state, there will be relatively few transfer specs (probably a single digit number)
and there will be dozens of actuator profiles.
Itâs not like I am going to challenge anyone to a duel over this matter. If we go with two SCâs, then cool, if we stay with three, then fine. I think going
with one meeting divvied up three ways is a bad idea, but can live with it.
I wish I never brought this up, the time would be better spent on an actuator profileâ
Joe B
From: openc2@lists.oasis-open.org <openc2@lists.oasis-open.org>
On Behalf Of Dave Lemire
Sent: Tuesday, February 25, 2020 10:04 AM
To: duncan sfractal.com <duncan@sfractal.com>
Cc: OASIS OpenC2 List <openc2@lists.oasis-open.org>
Subject: [Non-DoD Source] Re: [openc2] Subcommittee Reorganization - common meeting
Based on taking notes and doing minutes, I must disagree somewhat with "virtually identical answers with respect to workload". Alex stated he had more work than people to do it. My overall assessment
of workload, as discussed at the TC meeting would be
IC-SC - moderate workload
What all co-chairs did commonly report was a concern about attendance at SC meetings and level of involvement. As Duncan and others have described the best way to address this may be for the
small number of participants to be getting black-on-white in order to prompt feedback and improvement from interested parties. I think it's fair to say that at least the IC-SC meetings have drifted away from specifics toward generalities since the specifications
were approved, and moving back toward specifics might prove useful.
WRT to specifics, I was happy to see Duncan's email about SBoM AP content and look forward to reviewing it.
HII Mission Driven Innovative Solutions (HII-MDIS) â formerly G2, Inc.
Technical Solutions Division
302 Sentinel Drive | Annapolis Junction, MD 20701
Email:
dave.lemire@g2-inc.com
Work: 301-575-5190 |
Mobile: 240-938-9350
I disagree with âthe relative work loadsâ. As you recall, on the evening monthly
TC call I asked the same questions of all three SCâs and got virtually identical answers with respect to workload. I personally think the IC-SC has the highest workload, and I think my plugfest experience also supports this (more opensource, more transfer/transport
specs).
Wrt âboiling all the subcommittees into a single timeslotâ I agree that Iâd prefer
each SC meet on itâs own for the reasons Michelle gave â and note she was explaining why NOT to combine the LSC and IC-SC. Iâm just arguing that if we must combine, then combine them all. I still maintain AP/IC have more in common than L/IC, but Iâd prefer
we remain with 3.
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at http://vsre.info/
Vasileios,
Understood.
Duncan,
In addition to the reasons I pointed out earlier in this email chain, AP SC was âsingled outâ due to
the relative work loads. Inspection of the number and scope of the action items from the plug fest validates the hypothesis.
The notion of boiling all the subcommittees into a single timeslot with a common agenda is a different
topic and (my opinion) would be an error for the reasons that Michelle Barry pointed out circa Feb 18. (Diluting the expertise and focus of the SC, these are different concerns, the appropriate means to address the time and attendance issue is via changing
the tempo and she stated better than I could so advise reread her email rather than have me plagiarize. )
Regards
Joe B
I meant exactly what Duncan described. Common meetings, and one agenda that divides\allocates time based on the requirements of each committee.
RE: âSo the LS-SC and the IC-SC should meet together and have a common agenda (for an indefinite period)â
& âIf we have common meeting times and common agendas, then isnât that a single subcommittee?â
Common agendas can have multiple meaning â it could just mean they each get their piece of the overall agenda.
I do like the idea of âtrialingâ the meetings before changing our formal organization. This would give us data on
what differences occurred and whether it was an improvement.
I am against singling out 2 of the 3 subcommittees. I still donât understand why the LSC/ICSC are the two to combine.
We could consider a periodic (every 2 weeks? Every month?) 1-hour meeting that had a nominal agenda of the first
20 min for LSC, the second 20 min for AP-SC, and the third 20 min for IC-SC. I picked equal times because of my polling of the SC cochairs at the last TC meeting. But I would expect the numbers to vary weekly. We would be flexible based on agenda topics â
eg if LSC had less, then it would get less. Each section of meeting would still be run by respective SC cochairs. At the cochair tagup the cochairs could do the time/agenda allocation for the following week.
iPhone, iTypo, iApologize
I am not trying to be flippant or anything like that, I honestly donât understand something. If we
have common meeting times and common agendas, then isnât that a single subcommittee?
I have always liked the notion of co-chairs, provides a backup (in the event that somebody has a life
and goes on vacation or whatever). Keeping the co-chairs down to two people allows for agility. Four co-chairs could be a little clumsy and I think OASIS has a rule that you can have at most two.
In the context of separation of concerns, I am confident that most of us can agree with that. I donât
think that formally defining separate subcommittees is required to make that happen. It is reasonable to assume that if we succumb to our totalizing instincts, then we can trust our colleagues to remind usâ
Regarding participation: OpenC2 is my first rodeo, so the following is an uneducated opinion. Am I
concerned with the fact that we have over 100 people in the TC and fewer than a dozen at any particular SC meeting? Well yes, I am. I donât know if it is a natural lull, a lack of interest, or if it is due to people actively undermining us, but...
-
I will take the results of the first Plug Fest as an indication that there is genuine interest in OpenC2.
-
I suspect that there are some people who are actively making efforts to undermine OpenC2, but I would guess that there are very few.
-
I suspect that surges and lulls are normal. We are seeing a number of topics in the AP-SC and as we gain experience, we will identify needed changes and activity will increase.
NOTE: Those three bullets were my uneducated opinion.
Regardless of the reason, I doubt that the SC organization will significantly impact the likelihood
of a person participating (or not). Getting a draft released for comment will do much more for participation. (Again, that was my uneducated opinion)
I agree with the notion of leaving the AP-SC as is and combining the LSC and IC-SC, but I am not at
the point where I am going to ask anyone to choose pistols or sabers. I am fine with whatever the majority decides.
I agree with Vasileios. Unless there is some compelling reason for reorganization beyond time effectiveness, sharing
meeting times would seem to be a good compromise position.
I would keep the organizational structure the way it is. I donât think that re-organization will foster higher participation
right now, but I do understand that having one group will allow more people to stay in the loop by aggregating them all together at this point . I would say keep separation of concerns but merge the meetings. So the LS-SC and the IC-SC should meet together
and have a common agenda (for an indefinite period).
Willing to go along with it either way.
It would be very helpful to understand what more people think about the reorganization. Please respond with where
you are on the issue. Are you strongly for it, for it, strongly against it, against it, willing to go along with the majority either way, donât really care, other thoughts?
My concern is my standards experience tells me that most people will keep quiet on issues like this and vote yes
because they trust the leadership. In this case the leadership is divided. Being honest, I happen to be against the reorganization for the reasons Iâve stated in all my other emails, slack message, etc. So the âvote yesâ because everyone votes yes hurts my
case and therefore Iâm trying to distinguish between the ânot raising objectionâ and the âactually forâ.
It would be very useful to get more input â even if you say âI really donât careâ.
iPhone, iTypo, iApologize
A reorganization of the subcommittees was proposed during the January 2020 TC meeting. The purpose of this email
is to present the resolution, provide background information and initiate deliberations on the topic. Once the deliberations are complete, Dave Lemire will generate an electronic ballot in accordance with the direction provided by the TC during the February
TC meeting.
NOTE: Review the deliberations and if you believe that I did not capture the point correctly in the summary of the
deliberations then provide the correction and/or provide additional points. If there is an error, then accept that it was an honest mistake on my part.
FURTHER NOTE: SLACK messages are not available to all our members. I will attempt to transfer any SLACK messages
to the oasis email relay, but it is preferred if you use this email as the medium for deliberations.
RESOLVED: The OpenC2 Technical Committee shall form a new subcommittee to be known as the âLanguage and Architecture
Subcommitteeâ. Upon formation of the new subcommittee, the âLanguage Subcommitteeâ and the âImplementation Considerations Subcommitteeâ shall transfer their activities to the new subcommittee.
 A proposal
to transfer the activities of the LSC and ICSC to a new SC was proposed during the January Monthly TC
 The general
consensus was to revisit the issue after the Plug Fest and email deliberations
 Objections
were raised during the February Monthly TC meeting.
 There was
general consensus with the approach of continuing the deliberations via email and upon conclusion of the email deliberations a decision will be made via electronic ballot.
 After the Plug Fest, the proposed new subcommittee was brought up via email.
 The net effect
is to combine the LSC and ICSC into a single subcommittee
 The AP SC
will maintain its current tempo and leadership
 Objections
to the proposal were made known via email on Feb 18, 2020.
 Summary of Deliberations
 Statement
FOR
 Level of effort
required to revise and maintain is substantially less than the initial draft
 The scope
of the LSC and IC-SC are at a 'systems' or âarchitecturalâ level while the scope of the AP-SC is at a 'component' level therefore logical to combine the 'system' or 'architectural' tasks in one subcommittee and the 'component' tasks in a separate subcommittee
 The results
of the Plug Fest seem to validate the proposal in that the vast majority of the issues identified were component level
 Statement
AGAINST
 Should retain
separate subcommittees to retain their focus and maintain separation of concerns
 Several (structured)
subcommittees permit attendees to focus their attention on their areas of interest and expertise and avoid diluting the meeting.
 Rebuttal to
the statement AGAINST
 No rebuttal
offered
 Rebuttal to
the statement FOR
 The reduced
workload is more appropriately addressed by changing the cadence of the meeting rather than broaden the scope of the subcommittee.
 Do not agree
that the current Language and IC-SC are more similar to each other, in fact [one individual] thinks that the AP-SC has more in common with the LSC than the IC-SC.
'Adnius ad retinedam puritem noster peciosus corporalis fluidorumâ'
|