search

oasis-tcs / openc2-oc2ls

OASIS OpenC2 TC: GitHub repository used to propose and track changes to the OpenC2 Language Specification as new working draft level revisions are created and the associated CSDs mature
https://github.com/oasis-tcs/openc2-oc2ls
Other
15 stars 19 forks source link

Add SLPF Args to Language Spec #352

Open sparrell opened 4 years ago

sparrell commented 4 years ago

The SPLF Actuator Profile mostly uses terms used in the language spec but does have some extensions. Several of the extensions are to the command arguments:

I propose these and their subtending attributes (eg "ingress" and "egress" for "direction" be added to the language specification.

My arguments for these arguments (haha) is similar to Issue #351 so I won't repeat here.

jmbrule commented 4 years ago

This issue has been discussed at great length and the points made in issue 351 are not new. In the absence of new issues (not uncovered in the original deliberations) and/or an increase of new members (who may be numerous enough to overcome the original vote) I do not understand the purpose of rehashing an issue that has been proposed, deliberated on and voted on.
Suggest closing this issue until new points are made and/or a wave of new TC members join

TobyConsidine commented 4 years ago

While I fully approve of the spirit of the last comment (don't go hunting for bodies already buried), I think for the LS, the issue is commonalities. If the Parameters suggested by Duncan appear (or look to appear) in multiple APs, then we should promote them into the Language. If they appear in exactly one profile, we should not.

I am not sure which of these cases is in play here.

jmbrule commented 4 years ago

Agree with TobyConsidine. At this point, we have exactly ONE profile, so it would take quite a leap of faith to call it 'common to many profiles'. All I am asking for is some data and/or new info. For now, let's put our totalizing instinct to rest.

jmbrule commented 4 years ago

Minor nit with Toby's comment: We need to use judgement. If an argument shows up in multiple profiles, then yes, we should look at bubbling it up. If it shows up in two very similar profiles, then leave it in the profiles and avoid polluting the language spec.

jmbrule commented 4 years ago

Issue 94, 351 and 352 are essentially the same issue. One camp would like to move all specifiers, arguments etc 'up' to the language spec and the other camp would like to keep the specifiers, arguments etc that are unique to a particular set of actuators in the profiles. May we close 94 and 351 and put all the deliberations in 352? Keeps us from having to repeat the deliberations in multiple threads

sparrell commented 4 years ago

I disagree vehemently with the summary of previous agreements. I agree we did discuss it and I agreed to approve only with the understanding that we would revisit this after approving the 1.0 spec. I have no disagreement that vendors can extend the language. But I think terms used in any OpenC2 approved specification should eventually be in the language. All of the terms under discussion will be used in other AP's.

sparrell commented 4 years ago

I disagree this issue #352 is same issue as #94. Issue #94 would remain in SLPF if #352 is rejected. If #352 is agreed to, #352 only states to agree to what is already in the SLPF.

sparrell commented 4 years ago

Maybe #352 should be deleted in favor of #351 - ie each term added/debated/rejected on it's own.

dlemire60 commented 2 years ago

discussed at triage, deferred to future, same as #351, and for same reasons: awaiting use in multiple APs.