Firewall Profile: openc2 target type

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

QUESTION: 
Do you agree with the following specifiers for the openc2 target type? 
	Version:  Number indicating the version of the language specification 
	Profiles:  list of the profiles supported by the actuator (in this case 'stateless-packet-filtering').  
	Profile-options:  A 3D array indicating the options supported by the profile
	Serialization: list of supported serializations that MUST include JSON

BACKGROUND: 
The language specification has the openc2 target type but none of the specifiers have been defined.  We need this target type for the query command.  

During the March 28 AP SC meeting,  a participant identified the need for a 'heartbeat' to confirm that the device is online.  Initially the thought was to have a 'heartbeat' target type that would return the openc2 version but we discussed the idea of using the  pre-existing openc2 target type and define a 'version' specifier.  

The current version of the language spec has the 'OpenC2' target type with the description of "The OpenC2 object is the summation of the actions, targets and profiles supported by the actuator. The target is used with the query action to determine an actuator's capabilities"  
A profile spells out the required actions, targets, options etc.  so a 'profile' specifier that lists the supported profiles was defined.  I would also be interested in a 2D array where the first element is the profile name and the second element is a path to where the schema can be located.  

An actuator profile also provides actions, targets, command options etc. that are optional to implement so a 'profile-options' specifier was defined. The data type for the 'profile-options' needs to be a 3Xn array so that the profile (where the option is defined), the optional command and the optional command-option can be put in context.  

The DOD and an FFRDC laboratory will be starting an effort to create a prototype implementation of OpenC2 for unmanned systems.  This particular environment may have a low SNR and SWaP constrained and would like to investigate a binary serialization so a 'serialization' specifier was defined which must include JSON (in accordance with the Language Spec)   

Look at the write up on page 19 of the draft Firewall profile.  I attempted to capture the query openc2 command and acknowledge that it is a first draft.  Please provide comments and/or additional specifiers we may need to support the query openc2 command.    Also, we need to feed this back to the LSC.  

BTW, here are a couple of threads I cooked up.  I used a # for comments, but please note that openc2 itself does not support comments.  

# In the query the specifier 'Version' is present but not populated . 
# Indicates what information is required of the actuator rather than have the actuator send every byte of information it has about itself....
# Also note response type of complete.   
{
    "Id"=12345
    "action": "query"
    "target": {
        "openc2" {
	Version:
        }
    }
"options"{
Response_type=complete}
}

The corresponding response would be:
# Case one, things are OK
    "Id":12345
    "Status":200
    Results{
	Type: openc2{
	"Version": 1.0
}
}
#  Case two, either a time out at the transport layer or
    "Id":12345
    "Status":400 
    Results{}

# In this thread we only care about the profiles supported and version of openc2.  
#  'Version' and profile are present but not populated. 
# Indicates what information is required of the actuator rather than have the actuator send every byte of information it has about itself....
{
    "Id"=12345
    "action": "query"
    "target": {
        "openc2" {
	Version:
	Profiles:
        }
    }
"options"{
Response_type=complete}
}

#The corresponding response would be:
# response one, things are OK
    "Id":12345
    "Status":200
    Results{
	Type: openc2{
	"Version": 1.0
	"profiles": stateless-packet-filtering, http://some.url.org 
}
}
#  Response two, error
    "Id":12345
    "Status":400
    Results{}

# Here we know the version and profile, but want to know the options
#  profile-options is present but not populated 
{
    "Id"=12345
    "action": "query"
    "target": {
        "openc2" {
	Profile-options
        }
    }
"options"{
Response_type=complete}
}

#The corresponding response would be:
# response one, things are OK
    "Id":12345
    "Status":200
    Results{
	Type: openc2{
Profile-options:  
	stateless-packet-filtering, deny domain-name, complete
	stateless-packet-filtering, deny domain-name, respond-to
	stateless-packet-filtering, deny hostname, complete
	stateless-packet-filtering, deny hostname, respond-to
}
}
#  Response two, error
    "Id":12345
    "Status":400
    Results{}

# In this case, we don't know anything and want the actuator to tell use everything
#  None of the specifiers for the openc2 target type are present, so the actuator knows it has to respond with everything it has
{
    "Id"=12345
    "action": "query"
    "target": {
        "openc2" {
        }
    }
"options"{
Response_type=complete}
}

# The corresponding response would be:
# response one, things are OK
    "Id":12345
    "Status":200
    Results{
	Type: openc2{
		Version: 1.0
		"profiles": 
			stateless-packet-filtering, http://some.url.org
			our-next-oasis-profile, http://someother.url.org 
		Profile-options:  
			stateless-packet-filtering, deny domain-name, complete
			stateless-packet-filtering, deny domain-name, respond-to
			stateless-packet-filtering, deny hostname, complete
			stateless-packet-filtering, deny hostname, respond-to
			our-next-oasis-profile, scan directory, coolactuatorspecificoption
			our-next-oasis-profile, scan file, coolactuatorspecificoption
			our-next-oasis-profile, scan directory, coolactuatorspecificoption
			our-next-oasis-profile, contain username, 
		Serialization:
			Json
			Cbor
			Xml
}
}
#  Response two, error
    "Id":12345
    "Status":400
    Results{}