I believe it has already been agreed within the IC-SC that it should create at least two transport specifications: https api, and pub/sub. At previous IC-SC meetings, there appeared some disagreement on whether more would be appropriate, and if only those two - which pub/sub was an issue.
I personally support many transport specifications- given some caveats. I think there should be only one OpenC2 transport specification for any given transport mechanism. Ie only one https-api openc2 transport spec, only one opendxl transport spec, only one opendds transport spec, etc.
I recognize some members have expressed concern this will lead to interworking problems. I don’t understand their point of view. Note multi-vendor implementations for some of these have already occurred. These multiple transport mechanisms already exist and are in use. OpenC2 will neither enlarge nor shrink their markets. They are is use wherewever they are in use. I just want OpenC2 to be able to be used in those enterprises instead of the existing proprietary C2. If interworking is required between enterprises using different transports then it should use an orchestrator2orchestrator enterprise2enterprise transport like STIX anyway (ie the internal could be opendds and the external could be STIX).
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize