[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [openc2] RE: [EXT] [openc2] Modifier to become Action-Option
I agree with Allan.
I do not think a Wiki is a good place to do deliberation. It is a good place to capture consensus after deliberation has occurred. Using a wiki will do one of two things:
1) Stifle discussion due to the pain of working with a wiki 2) Cause an explosion of data on the wiki to the point where you can not make heads or tails of what is going on.
IMHO a wiki should be use only after deliberation has happened and general consensus has been achieved.
Bret From: Allan Thomson <athomson@lookingglasscyber.com>
Sent: Thursday, September 7, 2017 12:22:35 PM To: Brule, Joseph M; Waltermire, David; Bret Jordan; duncan@sfractal.com; TC OpenC2 Subject: Re: [openc2] RE: [EXT] [openc2] Modifier to become Action-Option Joe – the proposal by David where the targets are a flat array works. On the wiki you capture my input as ‘nested’. I was pointing out a problem with the flat design that needs
to be resolved. We don’t need nested. We just need unambiguity of the JSON fields. Otherwise you have a broken spec. Allan Thomson,
CTO,
Lookingglass Cyber Solutions This electronic message transmission contains information from LookingGlass Cyber Solutions, Inc. which may be attorney-client privileged, proprietary and/or confidential.
The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe that you have received this message in error, please contact the sender, delete this message, and be aware that any review, use, disclosure,
copying or distribution of the contents contained within is strictly prohibited From: "Brule, Joseph M" <jmbrule@radium.ncsc.mil> All,
I am in the process of gleaning the relevant items from this thread (and other sources such as slack) so that we could move this to a wiki. A wiki will provide
a more concise and organized collection of the points and counterpoints.
I think if we work on our OASIS wiki, we will be able to provide the points, counterpoints and discussion in a single and easy to navigate location. This can
provide background and context to the discussion(s). Does it make sense to use the email distro as a means for communicating resolutions and other media (such as wiki) for deliberation? I am concerned that some
of the context and discussion will get obfuscated in a sea of email…. https://wiki.oasis-open.org/openc2/EncodingStyle
From: openc2@lists.oasis-open.org [mailto:openc2@lists.oasis-open.org]
On Behalf Of Waltermire, David A. (Fed) Multiple targets could be represented like this: { "action": { "type": "copy", "options": {} }, "targets": [ { "type" : "file", "specifiers: {}, "options": {} }, { “type” : “registry-key”, “specifiers: {}, “options: {} } ] } A single target could be represented as a single array member. Thoughts? Regards, Dave From: Allan Thomson [mailto:athomson@lookingglasscyber.com]
The only issue I see with Option 1 is that if there is an intention to have multiple targets in the same target specification. For example with Option 1 the following would *not* be possible as specifiers and options are now ambiguous. Option 1: { "action": { "type": "copy", "options": {} }, "target": { "type" : "file", "specifiers: {}, "options": {} “type” : “registry-key”, “specifiers: {}, “options: {} } } Whereas with Option 2 (the specifiers and options are not ambiguous): Option 2: { "action": { "copy": { "options": {} } }, "target": { "file": { "specifiers: {}, "options": {} }, “registry-key” : { "specifiers: {}, "options": {} } } } So if having multiple targets in the same target specification is not needed then it’s a non-issue. If multiple targets are needed then this problem needs a solution. Therefore I have a slight preference for Option 2 (*if* multiple targets are needed). Allan p.s. Option 1 could be solved by naming the specifiers and options as “file-specifier” and “file-options” but that is not ideal. From: <openc2@lists.oasis-open.org> on behalf of "Waltermire, David A. (Fed)" <david.waltermire@nist.gov> I have a preference for option 1 largely because I believe the BNF can be made more simple around this syntax, without having to account for specific target types. Enforcement
of specific target types and type specific options can then be handled post-parse by business logic enforcing content co-constraints. Regards, Dave From:
openc2@lists.oasis-open.org [mailto:openc2@lists.oasis-open.org]
On Behalf Of Bret Jordan Yes, I fully support this change. In addition to this we have design issue with our current structure. Today we have: { "action": { "type": "copy", "options": {} }, "target": { "file": { "specifiers: {}, "options": {} } } } This represents a bad form with its design. The action property is flat while the target is nested. We should do one or the other. There are two real options here, and they both
have the same semantic meaning. Personally, flat designs are generally more preferable, and they represent a good design principle (flatter is better than nested). The advantage of nested is you can quickly make parsing decisions about which struct to unmarshal
content in to based on the key name. So I can go either way, but we should pick one style of encoding. Option 1: { "action": { "type": "copy", "options": {} }, "target": { "type" : "file", "specifiers: {}, "options": {} } } Option 2: { "action": { "copy": { "options": {} } }, "target": { "file": { "specifiers: {}, "options": {} } } } Bret From:
openc2@lists.oasis-open.org <openc2@lists.oasis-open.org> on behalf of
duncan@sfractal.com <duncan@sfractal.com> An issue was discussed and resolved at the last Language Subcommittee |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]