[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [openc2-actuator] Resolution of Yu comments to the stateless packet filter profile
Dave – You are correct. It comes down to how the use of the word ‘optional’ is used and applied in context. I think the use of the word ‘optional’ is what is confusing if people think that means its optional to implement. Which could be the case if not careful. What your example below suggests is that it’s a mandatory feature that can be configured or used during a deployment. Therefore it’s not optional at all. It’s just a configuration setting. If possible I think avoiding the use of the word ‘optional’ would help clarity. Allan Thomson CTO (+1-408-331-6646) From: David Kemp <Dkemp@mobility-challenge.com> Define the word “optional”.
Something (like SHA-256 hash) is optional if the spec doesn’t require it to be sent in every message. The language spec currently has a hashes object where MD5, SHA1, and SHA256 are all marked (optional).
The next version of the spec will instead have a cardinality designation or 0..1 occurrences of each hash type in a message. The meaning is the same – messages can but don’t have to contain SHA-256 hashes. But if SHA-256 is MTI, then if somebody chooses to send it they can be sure that the implementation supports it. The conformance test must
If a feature is both optional and not MTI, then test 2 doesn’t have to be run. If it is optional and MTI, then test 2 must be run, and the product does not conform if it does not support the optional MTI feature. Dave From: Allan Thomson [mailto:athomson@lookingglasscyber.com]
If something is optional in all specs (language/profile) then the conformance test is a test of an optional feature. The test should not be exercised unless a product implements that optional feature. I would say ‘passing the test’ for an optional feature that isn’t implemented on a product is not correct outcome. I would expect the test report to indicate ‘not implemented’. Not that the product passed the test.
Allan From: David Kemp <Dkemp@mobility-challenge.com> Assume: A feature is shown as optional in all specifications (base language and profiles). If a conformance test tries to exercise that feature and gets an error (or if behavior is defined and the unit doesn’t perform as expected), then:
a.
if the feature isn’t “Mandatory to Implement” the implementation passes that test.
b.
if the feature is MTI the implementation fails that test. Dave From: Allan Thomson [mailto:athomson@lookingglasscyber.com]
Dave/Joe – For OASIS specifications typically I’ve seen MUST, SHALL, MAY, SHOULD ….etc used in normative clauses. Maybe I missed something in the original question Joe posed but something Dave said that caught my eye. “optional features that MUST be implemented”
Do you mean that the feature is optional in a base/language specification but an actuator profile makes it mandatory? If yes, then we have addressed this similar scenario we have in STIXPreferred by stating that the certification test is a ‘mandatory’ to perform and verify. When we state what is mandatory we also include what exactly is being looked for to prove that the feature is ‘implemented’ satisfactorily which typically goes beyond data but also includes behavior on the system when acting on the data/protocol. Regards Allan From: "Kemp, David P" <dpkemp@radium.ncsc.mil> MTI is standard IETF terminology (see e.g., rfc 7687). For conformance requirements:
OASIS usage conflicts with that of the IETF – they use mandatory as a substitute for required.
http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html: “If an extension is mandatory and it is not supported by the implementation,
then the implementation MUST reject the process definition. If the extension is optional and it is not supported,
then the implementation MUST ignore the extension. These two statements provide clear, unambiguous, testable directions to implementers of the specification.” “For example a document that claims conformance to a schema does not have to use any optional features. However, in another scenario, a protocol implementation target should implement optional features in case another
party using the protocol makes use of the optional features. In deciding how to dispose of optional features, issues that affect interoperability and portability need to be considered.” I can’t find any clear-cut guidance for what terminology OASIS uses to designate optional features that MUST be implemented. “Mandatory” is not it, since OASIS chooses to use it as a synonym of Required. “MTI” is therefore an unambiguous
alternative to “Mandatory to Send”, and unless OASIS can provide clearer guidance, we need to keep MTI to address static conformance issues that affect interoperability. Dave From: openc2-actuator@lists.oasis-open.org <openc2-actuator@lists.oasis-open.org>
On Behalf Of Brule, Joseph M Required can be interpreted as required for every command (vice required to implement). Stating ‘mandatory’ (without the implement part) doesn’t address the issue.
BTW, agree that mandatory would be a good term to use to indicate that it must pass a test.
From: openc2-actuator@lists.oasis-open.org <openc2-actuator@lists.oasis-open.org>
On Behalf Of Allan Thomson Joe – Why not just state ‘mandatory’ without the TI part. Mandatory is used in STIX/TAXII Interop Tests to indicate a mandatory test that must be passed to received STIXPreferred certification. Requiring features to be implemented is a common thing across OASIS groups and I’m not sure why we need 2 different ways of saying it (or verifying it). Allan Thomson CTO (+1-408-331-6646) From: <openc2-actuator@lists.oasis-open.org> on behalf of "Brule, Joseph M" <jmbrule@radium.ncsc.mil> All, Recall that we received sufficient votes on the firewall profile to be accepted as a CSD. BTW, this is a bit of a milestone. Many thanks to all of the contributors and to our firewall profile editors (Alex Everett and Duncan Sparrell).
I am in the process of resolving the comments that were provided during the voting period. The way I am going to proceed is:
·
Attempt to resolve the comment,
·
Contact the reviewer out of band to make sure I captured the comment correctly
·
Get an OK from them before forwarding it to the whole sub-committee. I gave you all of that boring information so that you would know why there is a lag between the comments and the proposed resolution to you.
At the end of this email, I pasted in an exchange with Sounil. For now, I will change the 'running' option to 'temporary'. If there is a better term, then please provide.
The term 'Required' vs 'optional' has been a recurring issue. In the context of the profile, the term 'required' means that it must be implemented, however required could be taken to mean 'required' for each command.
I would like to use the phrase 'Mandatory to Implement' (MTI) so that it is obvious we mean required to implement vs required in each command. I have been advised that MTI is not acceptable to OASIS. If that is in fact the case, I would
like to draft a proposal to allow the phrase and see if Chet and Robin are on board with it.
VR Joe B ======= tear line email exchange between Yu and Brule ===== Thanks for the update. I’m good with all the proposed changes. As for an alternative to “running”, I will generally defer to the router/switch guys, but if I had an option, permanent (survives reboot) or temporary
(doesn’t survive reboot) would be a good alternative. Thanks Sounil From: Brule, Joseph M <jmbrule@radium.ncsc.mil> Date: Wednesday, May 30, 2018, 3:54 PM To: Yu, Sounil <sounil.yu@bankofamerica.com> Subject: Resolution of your comments to the Stateless Packet Filter Profile Sounil, |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]