slpf rule comment or description

[alevere]

I propose an additional slpf argument is added which allows for a rule comment or rule description such as 'ticket 40342322' or 'dev web to dev db'. We should allow for a brief string (<64 chars) that a firewall admin or other user can use to place a note on a specific rule. This is often used at organizations to help document rules and allow for people to understand the rules that are in place.

[jmbrule]

I think the scope of the OpenC2 specification is focused on machine to machine communications in order to fulfill the 'act' portion of the OODA loop. One could argue that annotating the steps made in the 'decide' or 'orient' part of the ooda loop are beyond the scope of 'Act'. If we were to decide that it is appropriate to annotate the decision making process, then I suspect that it would be something that we store at the orchestrator (aka producer), is closer to where the decision was made.
I do not see how the annotation influences how the command is executed at the actuator.

[alevere]

Almost every firewall has a field for a comment for a given rule. Often, an enterprise enforces a requirement to have a comment, as this aids with audits. E.g. who made this rule, when was this rule created. This doesnt necessarily answer who made the decision, as the comment is left up to the org/process. If we push a command/action, I think it is expected that in many cases either a ticket or request number must be associated with the action for audit purposes. Let me know if you think that helps clarify or not.

[Vasileios-Mavroeidis]

Was thinking the same for the ids-ap and I remembered that we have the same unresolved "issue" here. I concur with Alex that an optional description property would be quite helpful for auditing reasons. Even though that does not provide any additional refinement with respect to the mechanics of the command we want at a later date to possibly get info as to the purpose of issuing that command.

[alevere]

Addressed issue in #134