DKS22 - Conformance Profile for Options - SLPF CSPRD Comment

Page 24, line 11-ish on

 

I believe the conformance profiles listed (basic producer,  basic consumer, complete producer, complete producer) are over simplistic and pejoratively worded. The issue that created this need is the options
 in the SLPF. As designed implementing the options is âall or noneâ. This will lead to either added complexity in implementations (eg adding the âupdate fileâ command when it makes no sense) or partial compliance being the norm. Although it make the document
 longer, I think there need to be more conformance clauses of the type âIf the blah-blah option is supported then a conformant implementation must whateverâ and that these clauses be independent of one another (eg so a conformant openc2 consumer with the ip-connection
 option would not be required to have the update file command if it is a cloud virtual device with no files.

 

I think many independent conformance clauses for the different options would be better, but if we âmustâ have two profiles, they should not be pejorative words like âbasicâ and âcompleteâ which implies implementing
 the options is âbetterâ. Call them ârequiredâ and âoptionalâ or â1â and â2â or ânsaâ and âciaâ or whatever wouldnât imply which is better - oops nsa and cia probably wouldnât pass that test
😊 â so go with ârequiredâ and âoptionalâ.

 

 

Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

I welcome VSRE emails. Learn more at http://vsre.info/