I believe that these fields should be optional in the language spec and mandatory in the actuator profiles or implementation considerations as needed. I
think that the arguments that say to have the fields be mandatory in the language spec but then say to ignore them if needed contradict the meaning of a mandatory field. I also want to echo the point made by Duncan earlier that OpenC2 is a language, not
a protocol.
Regards,
Lisa
From: openc2-lang@lists.oasis-open.org [mailto:openc2-lang@lists.oasis-open.org]
On Behalf Of Jason Keirstead
Sent: Friday, January 26, 2018 9:37 AM
To: Waltermire, David <david.waltermire@nist.gov>
Cc: Danny Martinez <danny.martinez@g2-inc.com>; Duncan Sparrell <duncan@sfractal.com>; openc2-lang <openc2-lang@lists.oasis-open.org>
Subject: [Non-DoD Source] RE: [openc2-lang] We need your input on: mandatory vs optional, Header, id, version, timestamp, sender
To me, this email trail seems to be happening backwards, where folks are trying to justify why given fields should be mandatory - it should be flipped around. The justification
should be on the optional side. What is the justification for an optional timestamp - in what situations is it a burden on the producer to provide one? Copy the above for every discussed field.
Optionality creates implementation difficulty with any protocol and any standard. The more things that are optional, the more decision branches you have to create, and the more input and error conditions
you need to handle. It is also much more likely to create interoperability problems between products as they will end up with behavioral differences to the end user when the field is present or not present - things you can't cover in a data interchange specification.
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security
"Things may come to those who wait, but only the things left by those who hustle." - Unknown
From: "Waltermire, David A. (Fed)" <david.waltermire@nist.gov>
To: Danny Martinez <danny.martinez@g2-inc.com>, Duncan Sparrell <duncan@sfractal.com>
Cc: openc2-lang <openc2-lang@lists.oasis-open.org>
Date: 01/26/2018 10:17 AM
Subject: RE: [openc2-lang] We need your input on: mandatory vs optional, Header, id, version, timestamp,
sender
Sent by: <openc2-lang@lists.oasis-open.org>
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
All,
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".
V/R
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).
Duncan Sparrell
sFractal Consulting LLC
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.
Bret
--------------------------------------------------------------------- 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