Table in Section 3.4.2.1 should be split up.

[dlemire60]

The table in 3.4.2.1 combines two data types: action-targets and targets, which should be its own type definition in its own section (e.g., 3.4.2.2). It may make more sense to move targets to a new 3.4.2.17, so that the intervening sections .2 through .16 don't need renumbering, but from a logical content perspective, inserting it as 3.4.2.2 probably would be better.

[davaya]

Either would work. There are three general approaches: 1) keep type definitions in alphabetical order 2) keep type definitions "close" to others that use them (depth-first tree walk) 3) add new definitions at the end

From a reader's perspective 1 and 2 are easier to use but both require renumbering. 3 is easier for the editor.

I prefer 2.

[dlemire60]

The current list is mostly alphabetical, with the exceptions of the malformed targets, which would be second if we just split 3.4.2.1, and Command-ID which is oddly placed near the end. The "pain" of renumbering isn't that great. Given on the order of 20-30 members of this set, the depth-first tree walk wouldn't be that hard to maintain, but we'd need to create the initial version. Can we leverage the JADN source to create a list ordered that way?

3.4.2 Data Types

• 3.4.2.1 Action-Targets
• 3.4.2.x Targets
• 3.4.2.2 Date-Time
• 3.4.2.3 Duration
• 3.4.2.4 Feature
• 3.4.2.5 Hashes
• 3.4.2.6 Hostname
• 3.4.2.7 Internationalized Hostname
• 3.4.2.8 IPv4 Address
• 3.4.2.9 IPv6 Address
• 3.4.2.10 L4 Protocol
• 3.4.2.11 Message-Type
• 3.4.2.12 Namespace Identifier
• 3.4.2.13 Payload
• 3.4.2.14 Port
• 3.4.2.15 Response-Type
• 3.4.2.16 Command-ID
• 3.4.2.17 Version

[davaya]

Do it alphabetically.

A type that is created only to define another type can be kept with its parent. But our data types are intended to be re-used. I don't see anywhere except L4_protocol and port that "keep with parent" might apply, and even they could be referenced by future types. A type that is tightly associated with its parent and never referenced separately should appear in its parent's section, not with its own section number.

In the schema I moved Status Code from OpenC2-Response (its parent) to Data Types to be consistent with OpenC2-Command. Command and Response are the top-level types in one section, and all the referenced types are in another. Status Code should also be moved to 3.4.2.x in the LS document.