The interoperability question is the major consideration here. My experience in these matters has shown that if the goal of OpenC2 is to support multi-vendor, multi-product environments, then we need to ensure that the necessary bookkeeping
information is required to be present to ensure this interoperability. Making these fields optional may allow for less information to be provided in single-vendor scenarios, but this is at the cost of ensuring interoperability in multi-vendor scenarios. For
OpenC2 to be successful, we need to support both situations. If these fields (except version timestamp) are not made mandatory, there is no guarantee that these fields will be provided by all implementations. This will create a usability problem that is rooted
not in implementation, but in the standard itself.
The version question is a larger question of implementation agility. OpenC2 will evolve over time and it is important for tools to have the data needed to support this agility. This issue is lessened, but not eliminated in a single-vendor
scenario where agreement on the version can be managed across the deployed solution. Even in the single vendor scenario, it is unlikely that all components can be updated simultaneously. This means that different components in the deployed architecture will
need to be upgraded individually. Different components will need to be operating at differing revision levels, where version is helpful. This is exacerbated in multi-vendor scenarios where this issue will almost always be present.
I don’t believe the dozen or two bytes of extra information will make or break implementations or deployments. In my view it’s worth the gain in interoperability that will result. Perhaps we should be discussing how these fields can be
incorporated at both the individual command level and in collections of commands. IMHO, COMMAND-ID should be expressed as a at the individual command level. Fields like VERSION can be expressed in a collections of commands, or if a single command is being
sent at the individual command level. The requirement needs to be that it must appear at the individual command level if the command is not being exchanged as part of a larger collection of commands, or if the command follows a different model version than
other commands being exchange in a collection. This approach would allow for a few bytes to be saved around the VERSION, but is at the cost of additional complexity. I am not sure the extra complexity is worth it, but this should be considered with regards
to the language spec.
Regards,
Dave
From: openc2-lang@lists.oasis-open.org [mailto:openc2-lang@lists.oasis-open.org]
On Behalf Of Danny Martinez
Sent: Thursday, January 25, 2018 7:42 PM
To: Duncan Sparrell <duncan@sfractal.com>
Cc: openc2-lang <openc2-lang@lists.oasis-open.org>
Subject: Re: [openc2-lang] We need your input on: mandatory vs optional, Header, id, version, timestamp, sender
I have not weighed in until now because I do not entirely understand what the issue is here. As I understand it is not whether these fields should exist at all, but rather if the fields should be mandatory or optional. My problem is why
is the LCS even having this conversation? It seems more of an implementations consideration question to me. In effect I think both arguments are valid potential implementations of the OpenC2 language.
The question then comes in. Well if we leave everything up in the air to be implemented any which way then we will never have interoperability. I agree and this is precisely why I have been a big advocate of having a "minimum implementations
to conform". It is one thing to say my implementation is viable, and another to say my implementation interoperates with other implementation. Currently when we create a reference implementation we have the benefit to "fix the fight" we can choose what happens
on both sides of the communications path. This will not always be the case.
From a language spec perspective I believe these options should be "optional", but I would not be oppose to making them "mandatory" for a particular implementation. If this implementation ends up being our "minimum implementation to conform"
then in I agree that these options should be "mandatory".
On Thu, Jan 25, 2018 at 4:04 PM, <duncan@sfractal.com> wrote:
So 5 of the 29 LSC members have weighed in within 24 hours. Ideally I'd like to give at least another day or so to hear from a few others - and not just because
my view is losing at the moment :-).
And it's a slightly more nuanced vote that 3 to 2 since I read Dave's note as for most of Allan's proposal but agreeing with me that timestamp should be optional
(ie for timestamp its 3/2 the other way).
Everyone else - please let us know your opinions. Even if your opinion is "I don't care either way, just get on with it" - that is valuable input also (and shows
you are listening and care).
iPhone, iTypo, iApologize
-------- Original Message --------
Subject: [openc2-lang] Re: [EXT] [openc2-lang] RE: [Non-DoD Source] RE:
[openc2-lang] mandatory vs optional, Header, id, version, timestamp,
sender
From: Bret Jordan <Bret_Jordan@symantec.com>
Date: Thu, January 25, 2018 3:29 pm
To: "Brule, Joseph M" <jmbrule@radium.ncsc.mil>, "'duncan@sfractal.com'"
<duncan@sfractal.com>, openc2-lang <openc2-lang@lists.oasis-open.org>
So Duncan and Joe are against it. Allan, Bret, and Dave are for it.
--------------------------------------------------------------------- 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
--
Danny Martinez
Cybersecurity Engineer
G2, Inc.
302 Sentinel Drive, Suite 300
Annapolis Junction, MD 20701
Mobile: 407-257-0031
|