[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: "Technical Reports" in ITU
Iâm moving a specific suggestion from larger TC list to the ICSC list. I circulated a bunch of ITU work to TC mainly to spur language and AP efforts. But this is a separate proposal. The ITU makes recommendations (standards) on interworking
and intends to adopt OpenC2. Recs are the hardest to get politically but Iâm sure OpenD2 will go thru since they are anxious to get it. But I also recommend we send them some proposed Committee Notes (our side) to turn into Technical Reports (their side).
CTI chose to do their use cases as recommendation. I think weâd get less objection if we proposed our use cases as Technical Reports (TR) instead. TRâs require less formality and approval and are just as good at getting the word out. Note I still feel OpenC2
Specs should be ITU Recs. Itâs just the use cases (and how we relate to other SG17 recs) that would make easy TRâs. We could do one for each of the relevant technologies from the ITU view (ie how we relate with STIX/fgati, how we relate with malware sandboxes,
how we relate with DLT/distributed-ledger-technology-aka-blockchain, how we relate to identity systems, how we relate with 5G, how we relate to secure-multilocation-computing, how we relate to quantum, etc). Obviously the STIX/threat-intel is the main topic
â and might be multiple TRâs â but we can also get in on the ground floor of the other technologies and develop our Committee Note/TR on topic even before we get the details of language/AP finalized for the tech. This would both be consistent with our âuse
cases firstâ philosophy and might solve the Joe/Duncan âabstractionâ philosophical discussion (ie we probably agree on any particular use case when we are using actual use cases â itâs generalizing where we tend to get into angels-on-head-of-the-pin differences).
In the longer run, if we play our cards correctly, the TRâs will set the stage for eventually modifying the relevant ITU specs (on sandboxes, DLT, idam, 5D, SMC, quantum, etc) to recommend OpenC2 for command and control. Admittedly we are a couple of years
away from that but we need to set the stage now. So my suggestion is to get IC-SC to develop the Committee Notes/TRâs I mention above â ie we make Committee Notes designed to be ITU TRâs on relevance of OpenC2 to the work the ITU is currently doing. We should start with obvious ones (packet
filtering, endpoint, malware sandbox, âcomply to connectâ, â) but we should also do the more esoteric ones to get them from âbeyond our headlightsâ into âshining light on themâ. Iâd be happy to be a co-editor on any/all of these, but hopefully others can help
as well. Duncan Sparrell sFractal Consulting LLC iPhone, iTypo, iApologize I welcome VSRE emails. Learn more at http://vsre.info/ From: TC OpenC2 <openc2@lists.oasis-open.org> on behalf of "duncan@sfractal.com" <duncan@sfractal.com> Might not have been best one to start with. Hopefully todays rdmase has more meat in it of relevance to OpenC2. If nothing else, they should spark thoughts on what they should have had in them. Suggestions on improving the English would be welcome. Developing more concrete use cases (especially if used OpenC2
😊 ) would also be welcome. Back in the day most ITU recs were written in either French or English with some Japanese, but now the Chinese contribute more than everyone else combined, with Korea in second place. I consider us lucky we still meet and draft in English.
Some of the awkwardness is 2nd-language issues. Some is trying to do too much with too little effort - and therefore not doing good quality control. But some is compromised wording. I just was on a call that agreed to really
horrible awkward title as a compromise (allowed both sides to have their way â so its effectively meaningless to anyone not present. I made that point to no avail). âA camel is the compromise of a committee trying to design a horseâ. Outside eyes without baggage
help â ie comments welcome. I talked one group today into letting me put their work on github so we could track issues and do better change control. They are letting me try as an experiment. Hopefully that will catch on and make stuff like this easier in future. Of
course that means I need to do the work to get it on github.
😊 Duncan Sparrell sFractal Consulting LLC iPhone, iTypo, iApologize I welcome VSRE emails. Learn more at http://vsre.info/ From: Dave Lemire <dave.lemire@g2-inc.com> I took the time to read this on Friday. It's relatively high level, so I don't see a lot of potential to extract use cases from it. Also, based on the Chinese authors I presume this is English as a 2nd language, but it got me wondering if many ITU documents are as repetitive as this. Dave David Lemire,
CISSP Systems Engineer 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
Email (effective 1 April 2020):
david.lemire@hii-tsd.com
Work: 301-575-5190 |
Mobile: 240-938-9350 On Fri, Mar 20, 2020 at 4:33 AM Duncan Sparrell <duncan@sfractal.com> wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]