openc2-lang message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [openc2-lang] We need your input on: mandatory vs optional, Header, id, version, timestamp, sender
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: "Waltermire, David A. (Fed)" <david.waltermire@nist.gov>
- Date: Fri, 26 Jan 2018 10:37:01 -0400
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
- References:
- We need your input on: mandatory vs optional, Header, id, version, timestamp, sender
- From: <duncan@sfractal.com>
- Re: [openc2-lang] We need your input on: mandatory vs optional, Header, id, version, timestamp, sender
- From: Danny Martinez <danny.martinez@g2-inc.com>
- RE: [openc2-lang] We need your input on: mandatory vs optional, Header, id, version, timestamp, sender
- From: "Waltermire, David A. (Fed)" <david.waltermire@nist.gov>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]