Two hour meetings are hard. Most people have their schedules already full. Personally I think we already have too many OpenC2 meetings in a given week, so adding another Ad-Hoc meeting just means you will not get everyone
there.
Bret
From: <> on behalf of <>
Sent: Saturday, January 27, 2018 7:27:24 AM
To: openc2-lang
Subject: [EXT] [openc2-lang] RE: We need your input on: mandatory vs optional, Header, id, version, timestamp, sender
I agree we probably won't resolve over email but I do think the email
helped frame the debate.
I agree we should discuss on a call.
The 30-Jan LSC is devoted to getting the already agreed parts of the
draft out for vote and I'd propose this topic doesn't meet the 'already
agreed' part. It would be nice if we could but we don't have agreed text
so I think it should wait.
One possibility is to discuss at the Feb 6 LSC. Should we make it a 2
hour meeting to have time for this and other topics? or we could
schedule an ad hoc meeting?
Thoughts?
I'll address whether people should continue via email in a separate
thread.
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize
-------- Original Message --------
Subject: Re: [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
From: Allan Thomson <>
Date: Fri, January 26, 2018 4:20 pm
To: Bret Jordan <>, "Mathews, Mary L"
<>, 'Jason Keirstead'
<>, "Waltermire, David"
<>
Cc: openc2-lang <>
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://clicktime.symantec.com/a/1/rzmnVi1IeIASqE6KB4K9STKUUCa2pQZXjNGw12MJsOc=?d=hHuq-kYiS44_e-DEhUUcczwXyD1UL9GyQO-rTnGBIqENG_0kXDDFHDLktYWxbhJ9gdgZ1m9ogNW_ktEyCOHYIAqMy_HPyOegip8XkUWv0K9tpMjC1sqJeKedAm1QF9gbmaomDtaRPTwDANk1lvsQ3nMoG71Y3o-V-hraizPDJFWJrF_zKsPiqV-iv2zwdchAzl89MX0iwaYnZj_XIO2IVZgAkWynSYw0_qIsJlOBEspuac4XiYCU1pzaKQhY9TGxWJKZzI51FsvTxtvSWkqE_f1ITlUWmPPwYDK-N-sotcwYe_n2iyPkbpyOcBRngFRRWfmrXsTIPguAVyRnXDBnKToEGKw55vxFQbOMclb7BNrkGOSCcCryMKiEY_mtMQxCqxF0nk-1nBBwfgtJPcT44Ko-6lzLoJ4mDqE2dJSZv8y5y_HVO8-Sm2KdteSqM6ugY7IQYFX-1abs6sbQ5tpku3-CGoSoMUvBR6CLXpuQXsNH8GLTAPpeB-p9Q-vPm0lb_GSko47Hq7M3ZzYZbBxEmySZfPAbOSzJiLSYwvI7YbfrJruhBOVYsSh7eJAH7g%3D%3D&u=https%3A%2F%2Fwww.oasis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php
--
Danny Martinez
Cybersecurity Engineer
G2, Inc.
302 Sentinel Drive, Suite 300
Annapolis Junction, MD 20701
Mobile: 407-257-0031
---------------------------------------------------------------------
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://clicktime.symantec.com/a/1/rzmnVi1IeIASqE6KB4K9STKUUCa2pQZXjNGw12MJsOc=?d=hHuq-kYiS44_e-DEhUUcczwXyD1UL9GyQO-rTnGBIqENG_0kXDDFHDLktYWxbhJ9gdgZ1m9ogNW_ktEyCOHYIAqMy_HPyOegip8XkUWv0K9tpMjC1sqJeKedAm1QF9gbmaomDtaRPTwDANk1lvsQ3nMoG71Y3o-V-hraizPDJFWJrF_zKsPiqV-iv2zwdchAzl89MX0iwaYnZj_XIO2IVZgAkWynSYw0_qIsJlOBEspuac4XiYCU1pzaKQhY9TGxWJKZzI51FsvTxtvSWkqE_f1ITlUWmPPwYDK-N-sotcwYe_n2iyPkbpyOcBRngFRRWfmrXsTIPguAVyRnXDBnKToEGKw55vxFQbOMclb7BNrkGOSCcCryMKiEY_mtMQxCqxF0nk-1nBBwfgtJPcT44Ko-6lzLoJ4mDqE2dJSZv8y5y_HVO8-Sm2KdteSqM6ugY7IQYFX-1abs6sbQ5tpku3-CGoSoMUvBR6CLXpuQXsNH8GLTAPpeB-p9Q-vPm0lb_GSko47Hq7M3ZzYZbBxEmySZfPAbOSzJiLSYwvI7YbfrJruhBOVYsSh7eJAH7g%3D%3D&u=https%3A%2F%2Fwww.oasis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php
