Many t&c systems support some form of namespaces in their database definitions. For example a "parameter" might be associated with a certain namespace ("/myagency/mymission/mysystem/mysubsystem/batv1") or a command as well. XTCE supports a kind of namespace through the spacesystem tree. GSFC's ITOS supports namespaces in the database. (the other one, ASIST does not). And so forth.

In the spec PDF, there is a lot of inconsistency about how XX Message Additional Information tables appear in the document.

Some have (mostly) heavy cell borders - ex: Table 8-36. Directive Response Message Additional Information

Some have normal cell borders - ex: Table 8-140. Command Request Message Additional Information

Some have both in the same table - ex: Table 8-31. Directive Request Message Additional Information

Having heavy cell borders leads to a propensity to add cells with inconsistent cell borders, unless care is taken by the editor. Because of this, I recommend using normal cell borders on all these tables. Normal borders are used in many of them and they look fine.

Similarly all the XX Message Header Field Values tables should be updated in the same way.

Additionally, there are other similar tables that follow this basic construct and should also be updated:

• Table 6-9. Ordinal Date and Time Field Type Definition
• Table 6-10. Response Status Substructure
• Table 8-3. Mapping of Message Header Fields to the C2MS Subject Name
• Table 8-9. Pass-Related Occurrence Types
• Table 8-10. Telemetry Limit Violation Occurrence Types
• Table 8-11. Command Verification Occurrence Types
• Table 8-12. Miscellaneous Occurrence Types
• Table 8-13. Log Message to Echo a Directive Request Message
• Table 8-14. Product Message to Echo a Directive Request Message
• Table 8-20. Examples of Start and Stop Times
• Table 8-26. Meaning of Response Status and Return Value with Recommended Actions
• Table 8-37. Group Hierarchical Associations
• Table 8-160. Meaning of RESPONSE-STATUS and RETURN-VALUE with Recommended Actions
• Table A-1. Software Class and Subclass Categories

Finally, - Table 8-161. Example Scenarios Using the Set of Product Messages should keep the format of the cells generally, but needs to be cleaned up.

As a note, there are some tables where the structure of the table is easier to distinguish with some heavy borders and these should remain. These are related to the XX Message Subject Naming Tables.

A minority (nine out of 60+) of "Properties of Miscellaneous" tables have lines for Miscellaneous Elements only to state that they are "not used". This is superfluous and inconsistent with most other tables of this type. The "not used" aspect is knowable by the ME not being listed either in this table or its preceding "Subject Naming" table.

This does not apply to the following tables, since they have some not used MEs in between others that are used, so they do need to be specified:

• Table 8-86. Properties of the Miscellaneous Elements for the Telemetry TDM Frame Message
• Table 8-91. Properties of the Miscellaneous Elements for the Telemetry Processed Frame Message

Additionally, "Table 8-182. Properties of the Miscellaneous Elements for the Navigation Data Message" lists ME6 but without any other information, including "not used". Upon review, though, it is not used, so the line should simply be removed to avoid confusion.

Item 1 - Table 8-62 Resource Message Additional Information is blank for NUM-OF-DISKS Type and Presence, should be U16 and R.

Some messages have an inconsistent layout or section naming for their "Message Subjects" section. These need to be brought into a standard from. Messages that have this issue:

• Section 8.3.1.1 Log Message Subject Names does not start at the right spot. It should begin before Table 8-5. Log Message Subject Naming. Additionally it should be "8.3.1.1 Log Message Subjects" (this is being fixed in the resolution of C2MS12-43)
• Directive Response and Requests Messages to do not have 'Message' in the section heading. (Instead of "Directive Response Subjects" it should be "Directive Response Message Subjects" to be consistent with others.

Late in C2MS 1.1, we aligned SDTF error levels across the specs. 1.1 initially used 'Severe' for the highest level of concern. Later, we changed this to 'Critical' as this was better alignment with XTCE. Although the document text was all changed, we had three model diagrams that referred to 'Severe' in notes: Log Message, Heartbeat Message and Device Message. The notes in these diagrams all need to be fixed to use 'Critical' instead of 'Severe'.

Note that Log Message is already being fixed as part of the proposed resolution for C2MS12-43. Therefore, this issue only addresses Heartbeat and Device Messages.

The SM&C defines a set of mission operations services. At the bottom of this we believe there's an SM&C MAL message.

We believe that if we define a C2MS MAL message and appropriate delivery (addressing) – that any C2MS service could flow over a C2MS implementation.

SM&C is a CCSDS spec that defines a set of ground system services, it is mainly Parameter (Mnemonic) value based (low level info is largely gone except they've added a packet construct recently). At the bottom of SM&C is the MAL message. The MAL message is technically abstract and one is to map it to your transport technology of choice – but perhaps there's no reason to literally implement a MAL message on the GMSEC bus. Determining details like "how will this really work" and so on would be part of this effort.
Once completed, we then say to SM&C folks that we could support an SM&C service. There's an additional facet related about tying into XTCE.