Firewall Profile: Should we consider an optional target type for importation?

["Brule, Joseph M" <jmbrule@radium.ncsc.mil>]

QUESTION: 
Should the firewall profile create an 'ap-slpffw' target type that will be optional for stateless packet filter firewalls?  

BACKGROUND:  

The following is NOT consensus attained from the actuator profile subcommittee nor any subset of the subcommittee.  The following is my opinion only and request confirmation or rebuttal. 

The current draft profile requires implementation of the 'query openc2' command.  The Language Specification has the openc2 target type.  The use case for query openc2 is to enable the orchestrator or openc2 producer to determine the capability of the actuator.  This use case is general enough such that it makes sense for us to present proposed specifiers when appropriate.  

The 'openc2' target type is not appropriate for some of the queries we may need to support.  For example a scenario where the orchestrator needs to confirm (or determine) if a particular ip-connection being denied.   I strongly suspect that there is a wide variance on how devices manage information so a query for a particular file, list or other setting does not seem pragmatic.  

Section 2.2.6 of the language specification spells out a means to import data objects from other specifications.  It seems logical to me that we can use this capability to create a target type optimized for stateless-packet-filtering.  I selected the abbreviation of ap-slpffw.   (the 'L' is necessary,  otherwise the acronym for 'stateless packet filtering' is the same as 'stateful packet filtering')  

Please review section 2.2.1.2 (pg. 17) of the googledoc.  Please provide your insights with respect to whether or not this is a sound approach.  If so, please provide your insight with respect to other specifiers we should consider and whether or not they should be optional or mandatory.  

VR

Joe B