Although I agree with Bret I think it should be clear to everyone by now that this issue is not going to be (re)solved over email. And more people from different or same organizations pilling on to the thread is not helping. In fact it’s
hurting.
Consensus is certainly not occurring nor is effective collaboration occurring either.
I suggest that a working call is a higher bandwidth opportunity to at least find some common ground.
Therefore scheduling a specific meeting for all interested parties to join would be good.
Allan
From: <> on behalf of Bret Jordan <>
Date: Friday, January 26, 2018 at 1:14 PM
To: "Mathews, Mary L" <>, Jason Keirstead <>, "Waltermire, David" <>
Cc: openc2-lang <>
Subject: [openc2-lang] Re: [EXT] [openc2-lang] RE: [Non-DoD Source] RE: [openc2-lang] We need your input on: mandatory vs optional, Header, id, version, timestamp, sender
The question is should some of these be required on all profiles. I think Jason is right here, that we should be phrasing the question in the reverse. We should make everything mandatory and then try
and find reasons why something should be optional.
Bret
From: <>
on behalf of Mathews, Mary L <>
Sent: Friday, January 26, 2018 2:09:48 PM
To: 'Jason Keirstead'; Waltermire, David
Cc: Danny Martinez; Duncan Sparrell; openc2-lang
Subject: [EXT] [openc2-lang] RE: [Non-DoD Source] RE: [openc2-lang] We need your input on: mandatory vs optional, Header, id, version, timestamp, sender
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:
[mailto:] On Behalf Of
Jason Keirstead
Sent: Friday, January 26, 2018 9:37 AM
To: Waltermire, David <>
Cc: Danny Martinez <>; Duncan Sparrell <>; openc2-lang <>
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)" <>
To: Danny
Martinez <>, Duncan Sparrell <>
Cc: openc2-lang
<>
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: <>
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:
[mailto:]
On Behalf Of Danny Martinez
Sent: Thursday, January 25, 2018 7:42 PM
To: Duncan Sparrell <>
Cc: openc2-lang <>
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, <>
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 <>
Date: Thu, January 25, 2018 3:29 pm
To: "Brule, Joseph M" <>,
"''"
<>,
openc2-lang <>
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
