Revised export of TAB comments - OpenC2

[Patrick Durusau <patrick@durusau.net>]

Greetings!

I caused confusion with the export of the comments I filed on behalf of
the TAB. I did not notice that the "description" of the issue was
missing from the export. My bad.

I have attached another export that includes the description.

Apologies and I will attempt (It's JIRA after all) to reset my default
export.

Hope everyone is having a great week!

Patrick

-- 
Patrick Durusau
patrick@durusau.net
Technical Advisory Board, OASIS (TAB)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau 

Issue key,Issue id,Affects Version/s,Issue Type,Custom field (Proposal),Description
TAB-1646,47574,Open Command and Control (OpenC2) Profile for Stateless Packet Filtering Version 1.0,Bug,"Suggest write:Â  ""MUST be conformant with Version 1.0 of the Language Specification""","3.1 1.4 reads: ""MUST be conformant with Version 1.0 (or higher) of the Language Specification"" as do several other conformance targets.

It isn't clear to me how a present application can be required to conform to a future version of a language not yet written. I don't know what test would be used or how it would be meaningful. "
TAB-1645,47573,Open Command and Control (OpenC2) Profile for Stateless Packet Filtering Version 1.0,Bug,Move the table to an appendix and mark it non-normative.,"While I can see Table 3-1: SLPF Traceability Matrix could be very useful, it really has no place in a conformance clause, unless you want it to be the conformance clause.

It is re-stating the conformance clause, something we all labor to avoid. There needs to be one and only one statement of conformance requirements. It just creates issues to attempt to restate conformance in another form. "
TAB-1644,47572,Open Command and Control (OpenC2) Profile for Stateless Packet Filtering Version 1.0,Bug,Remove the definition list.,"The relationship of:Â 

*****

OpenC2 SLPF Producers: Entities that send commands to and receive responses from OpenC2 SLPF consumers.
Basic SLPF Producers: OpenC2 SLPF producers that are conformant to all of the normative requirements identified in this specification as REQUIRED to implement.
Complete SLPF Producers: OpenC2 SLPF producers that are conformant to all of the normative requirements identified in this specification
OpenC2 SLPF Consumers: Entities that receive commands from and send responses to OpenC2 SLPF Producers.
Basic SLPF Consumers: OpenC2 SLPF consumers that are conformant to all of the normative requirements identified in this specification as REQUIRED to implement.
Complete SLPF Consumers: OpenC2 SLPF consumers that are conformant to all of the normative requirements identified in this specification

*****

to the rest of the conformance clause isn't clear. Are these separate statements of conformance requirements? If not, why doesn't each section of conformance requirements stand on its own? (No definition list)"
TAB-1643,47571,Open Command and Control (OpenC2) Profile for Stateless Packet Filtering Version 1.0,Bug,Reword as shown.,Correct ip-addr to ip_addr
TAB-1642,47570,Open Command and Control (OpenC2) Profile for Stateless Packet Filtering Version 1.0,Bug,Reword as shown.,Change hyphens ip-connect to underscores ip_connect
TAB-1641,47569,Open Command and Control (OpenC2) Profile for Stateless Packet Filtering Version 1.0,Bug,Reword as shown.,"Even allowing for my being unfamiliar with the spec., the following reads oddly:

""The â??allow ip_connectionâ?? command is required for openc2 producers implementing the SLPF.

If the â??allow ip_addrâ?? target is not implemented, then SLPF consumers MUST implement the â??allow ip-connectionâ?? command. Otherwise it is OPTIONAL.""

The problem is a grammatical one. I can't decide if it is the reference of ""otherwise"" (what's the condition?) or what is the reference of ""it?""Â 

I thought you had saved me in 2.3.1.2 where you wrote:

""If the â??allow ip_connectionâ?? target is not implemented, then SLPF consumers MUST implement the â??allow ip_addrâ?? command. Otherwise the â??allow ip-addrâ?? command is OPTIONAL.""

Ok, that clearer but very poorly stated. So fix the first one but let's think of a better way to say the clearer requirement in 2.3.1.2.

Suggest:

If SLPF consumer implements allow ip_connection, allow ip_addr is OPTIONALÂ 

if SLPF consumer does not implement ip_connection, allow ip_addrs is REQUIRED

Longer but trying to say it short leaves it confusing. 

 

 

 "
TAB-1640,47568,Open Command and Control (OpenC2) Profile for Stateless Packet Filtering Version 1.0,Bug,Correct the RFC citations.,Compare the RFC citations to:Â http://docs.oasis-open.org/templates/ietf-rfc-list/ietf-rfc-list.html
TAB-1639,47567,Specification for Transfer of OpenC2 Messages via HTTPS Version 1.0,Bug,Set and then use language for distinguishing normative from non-normative content. ,"There is no description or use of language to distinguish normative from non-normative text, including appendices. Sections 1.6 and 1.7 for instance. But there are other notes, examples, appendices, all of which should be non-normative. "
TAB-1638,47566,Open Command and Control (OpenC2) Profile for Stateless Packet Filtering Version 1.0,Bug,Set and then use language for distinguishing normative from non-normative content. ,"There is no description or use of language to distinguish normative from non-normative text, including appendices. Sections 1.6, 1.7 and 1.8 for instance. But there are other notes, examples, appendices, all of which should be non-normative. "
TAB-1637,47563,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,Label appendices as normative or non-normative,Appendices A-C are not labeled as normative or non-normative
TAB-1636,47562,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,"Before seeking public reviews in the future, do make serious attempts at all sections before posting for public review.

 

 

 

 

 

 

 

 

 ","The alleged conformance clause reads in part:

""MUST be structured in accordance with Section 3.4.1, and
MUST include exactly one ACTION specified in Section 3.4.1.1.""

If you go look for those sections:l

""3.4.1 Target Types
3.4.1.1 Artifact""

This is not a serious attempt at a conformance clause and volunteers have spent their time reviewing this non-serious attempt. "
TAB-1635,47561,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,"Complete Section 4. 

 

 

 

 

 

 

 

 

 ","Given the complexity up to this point, I assume 4 consisting of 3 sentences means it is incomplete and the specification cannot proceed until it is completed. Yes?"
TAB-1634,47560,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,"Insert cross-refs and/or hyperlinks as appropriate on 3.4 and elsewhere.

 

 

 

 

 

 

 

 

 ","So far as I can tell, there are no cross-refs and/or external links in section 3.4. Assume implementors are reading the text. What's the easiest way for them to obtain the relevant information? Yes."
TAB-1633,47559,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,"Truth is all schemas are subject to extension and you should write this and your conformance language to specify *conforming* extensions. 

 

 

 

 

 

 

 

 

 ","It's not easy making the rules. On one hand, 3.3.3 says: ""The list of ACTIONS in Section 3.2.1.2 SHALL NOT be extended."" but, then 3.3.4 says: ""Organizations may extend the functionality of OpenC2 by defining organization-specific profiles.""

You go onto say: ""OpenC2 defines two methods for defining organization-specific profiles: using a registered namespace or an unregistered namespace.""Â 

The first sentence enables an organization to define its own profile, the second sentence says OpenC2 has also defined two ways to extend. So, the limitation on defining more ACTIONS does not apply to the first case."
TAB-1632,47558,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,"My suggestion is to drop data import altogether since you can't specify it for all cases. How data gets imported is up to users of your specification and then it must meet your requirements. How it got there is anyone's guess. 

 

 

 

 

 

 

 

 

 ","We can all appreciate the need to import data but we all must make the choice to normatively provide a method for importing or, simply leave it alone. It's not a good idea to be half-way about it."
TAB-1631,47557,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,"Serious consideration of what ""conformance"" means when requiring the use of labels for the interchange of messages needs to be had. This isn't workable. 

 ","3.3.1.1 in an unnumbered section: Usage Requirements: says in part:

""Actions defined external to this section SHALL NOT be used.""

Well, that's direct enough but since no actions are defined sufficiently in this section to be useful, that's an odd ""SHALL NOT.""Â 

Yes? Perhaps only these labels are recognized but even that is different from this requirement. 

 "
TAB-1630,47556,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,"Make this paragraph a note and label as non-normative.

 ","Reads in part: ""The following actions are under consideration for use in future versions of the Language Specification.""

That's a note and non-normative if included at all.

 "
TAB-1629,47555,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,"Label the example as non-normative if not all examples are declared non-normative.

 ",Example following the unlabeled table (needs a label and number) is non-normative. Needs a non-normative label.
TAB-1628,47554,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,"Make this entire paragraph a note and label as non-normative.

 ","3.3.1.2 reads in part: ""The following targets are under consideration for use in future versions of the Language Specification.""

Speculations about the future are always notes and hence non-normative."
TAB-1627,47553,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,"Wouldn't it be clearer to say: These are labels for JSON values for the transmission of cybersecurity messages? The values of the labels are not defined but should fall within the semantic field of the label. 

Ex. Seeking donaldhacker@2600PennDC should be labeled as a query (Action), email_addr (Target), Actuator (sys specific)

There's no shame in being a uniform labeling. That is in and of itself a worthwhile task.","The wording of the ""action"" terms is confusing. These are labels for ""actions"" and not actions, such as: ""query - Initiate a request for information.""

No, query is a label for an action, when combined with a target label plus value and an undefined actuator, initiates a request for information. It is the undefined actuator and not the query label that makes the request. Yes? "
TAB-1626,47552,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,Create a namespace for actuator and resolves internal conflicts on what you do or don't say about it. ,"3.3, second paragraph, second sentence says: ""Other than identification of namespace identifier, the semantics associated with the ACTUATOR specifiers are beyond the scope of this specification.'

but, 3.3.1 ID 4, actuator says: ""The subject of the action. The actuator executes the action on the target.""

OK, which is it? If all actuator has is a namespace (I didn't see it in this draft), then it can do anything, not only ""executes the action on the target."" Yes?

 "
TAB-1625,47551,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,"Move up and restructure around these two items, assuming that is the scope of this draft.","""The scope of this specification is to define the ACTION and TARGET portions of an OpenC2 command and the common portions of an OpenC2 response. ""

If so, why did you wait until 3.3 to declare your scope? Moreover, why not use ACTION and TARGET as organizing principles for the draft? 

 "
TAB-1624,47550,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,Make the indicated text into a note. ,"""Implementations may use environment variables, private APIs, data structures, ..."" is clearly a note but is presented as normative text. Mark this as a note and note as always non-normative."
TAB-1623,47549,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,"To the editors, no doubt the text is clear and well-organized, to the casual reader, it is not. There should be hyperlinks to further details, when relevant and there should be some type of organization apparent to the reader. ",Are the Common message elements further defined elsewhere? The lack of kinking makes it difficult to find or say.
TAB-1622,47548,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,"Offset all ""for example and other examples from normative text. Just search for example and offset the following text as an example and mark as non-normative.","""For example, the JSON ""number"" type represents integers and real numbers as decimal strings without quotes, e.g., \{ ""height"": 68.2 }, and as noted in RFC 7493 Section 2.2, a sender cannot expect a receiver to treat an integer with an absolute value greater than 2^^53 as an exact value.""

Examples should be offset from the rest of the normative text. Here, had you done so, you would have noticed the ""as noted in RFC 7493..."" is a reference to normative behavior or expectations. Should be stated separately.

 "
TAB-1621,47547,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,"I would drop the notion of ""derivation"" as a noise word/concept and simply state the authorities for each data type. For your own identifier, simply state the rule, it isn't ""derived from string"" unless you are writing a grant proposal. ;)","No derivations, only descriptions. It isn't possible to verify the ""derivations"" listed in 3.1.2, especially identifier ""(TBD rules, e.g., initial alpha followed by alphanumeric or underscore)"""
TAB-1620,47546,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,"Terms like ""valid,"" ""information model,"" ""constructed,"" etc., are vastly overrated. Avoid them unless necessary. 

Try:

""The data types used in OpenC2 messages are:""

 as a model. ","With standards, those who write the least, write the best. 

Consider: ""The syntax of valid OpenC2 messages is defined using an information model constructed from the data types presented here:""

Compare:

""The data types used in OpenC2 messages are:""

BTW, your primitives are defined in XMLSchema part 2. No change necessary but we should all reference and not define data types."
TAB-1619,47545,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,Label 2. OpenC2 Language Description as non-normative with minor revisions.,Are there any requirements in 2 that can't be included elsewhere? Seems non-normative.
TAB-1618,47544,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,"Label 1.6, 1.7, 1.8 as non-normative. ","From the language in these sections, I presume them to be non-normative but they need a label saying so."
TAB-1617,47543,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,Create a normative vs. non-normative text statement and then mark text accordingly. ,"There is no description of markings for normative versus non-normative text. Generally that says text is normative unless marked as non-normative, all examples are non-normative, etc. "
TAB-1616,47542,Open Command and Control (OpenC2) Language Specification Version 1.0,Bug,Use  http://docs.oasis-open.org/templates/ietf-rfc-list/ietf-rfc-list.html to compare and correct the normative citations. ,"Sigh, with the production and maintenance of resources such as: [http://docs.oasis-open.org/templates/ietf-rfc-list/ietf-rfc-list.html] it's more than a little disappointing to find incorrect citations of RFCs.

Either the TAB has failed to adequately publicize these aids to editors or being seen, were not read by editors. I'll be gracious and say perhaps they need more publicity.

All of the RFCs that lack DOIs are incorrect. The IETF added those more than a year, possibly two years ago."

Attachment: signature.asc
Description: OpenPGP digital signature