Add SLPF Args to Language Spec

[sparrell]

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:

• drop_process
• persistent
• direction
• insert_rule

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]

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]

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]

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]

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]

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]

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]

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]

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

[dlemire60]

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