The Contact Reservation messages are not "Contact Schedule Messages" because in operational practice a contact schedule includes more data than simply time and antenna for an SV. Additionally, a "contact schedule" prorbably maintains some form of contact requirements, and may contain a command plan, set of automation tasks to perform, etc. So, we viewed reserving antenna time ans a PART of the schedule rather than the schedule itself.

It would be good to add a description about this to section 8.15.

And maybe look at each case where we use the phrase "scheduling messages". Like the title of 8.15, in particular. To me, it's OK that we say this because these are messages "related" to scheduling, but specific to reserving antenna time.

In the description for Req/Resp/Notify MEP, it says one response. However, it could actually be a series of responses, during or after which notification messages flow. Probably just need to cover this case to make sure its not overly proscribed.

Search for uses of this MEP and make sure their text aligns.

6.4.3.1 C2MS MSG Message Type, first paragraph says:

“Notification messages are sent to no specific consumer but are distributed to any component listening for that type of message.”

This is ok, but should find a way (and check throughout the doc) to say that they can be sent peer-to-peer (send message) pattern, if desired in the chosen architecture. In those cases, you do notify a specific component. Current language is very pub-sub oriented.

In 6.4, there is discussion for REQ and RESP, that ME1 means certain things. But ME1 is a subject element, while the message (header) has COMPONENT and DESTINATION-COMPONENT that also carry the same meaning. So consider reworking this to be more like ME1 and DESTINATION-COMPONENT field" or something like that.

Always, but especially if not using a subject, COMPONENT and DESTINATION-COMPONENT are also in effect, so do we need to say that two?

In the Header additional info table, the description for COMPONENT could be improved. Using the description for Subcomponent 1/2 as a guideline, perhaps: “Name of the component that produced the message." Examples are fine, I suppose.

Currently both these are optional. However, it probably doesn't make sense to supply both. They aren't mutually exclusive, because neither has to be specified. Consider some text to describe this. Technically, both would be allowed, but unusual.

Somewhere in the definitions part of the doc, we should probably make a note about CONTENT-VERSION, that it only changes if the content of that message chagnes. For example, in 1.1, there were a few messages that retained CONTENT-VERSION of 2019.

In the Subject Content line, we use [lowercase] to indicate a soft description, and [UPPERCASE] to indicate a field name. But compare this with Table 8 3. Mapping of Message Header Fields to the C2MS Subject. It could be that these are all field names??? If so, should probably capitalize all those (like [constellation]).

Either way, near that table, maybe add descriptive text about how [lower] and [UPPER] are used in those tables, along with other formatting description as needed.

Table 8-118. Mnemonic Value Data Message Additional Information under Mnemonic, Sample used to have RED-HIGH, RED-LOW, YELLOW-HIGH, and YELLOW-LOW, which have been deprecated and replaced with MNEMONIC.n.SAMPLE.m.ALARM-STATE. However, while that ALARM-STATE can indidcate if a tlm point is out of limits, it doesn't say whether it was high or low given a normal range.

We should consider if we should add an optional field called something like SAMPLE-OUT-OF-LIMIT-CHARACTERISTIC that says whether it was high, low or n/a. THe latter has to be htere to cover cases where it's not a range but more like true/false state.

My own feeling is that this isn't necessary. If a TLM Point is out of limits then the component or operator that has to eveluate what to do can simply look at the value and determin characteristics. But capturing it here for discussion.

Figure 6-1 Message Field Multiplicity should be redone. It uses the Log Message, but has incomplete constraints, and some of the fields in Log Message are deprecated, so it's not a great example. Consider Event Message instead.

Additionally, I can't find a diagram in the model that was used to create this, so a specific diagram, including the note, should be created in the model as well for consistency when the given example message might change in the future.

The GMSEC technical team has provided feedback that ____ (all, most, many) pub/sub products such artemis may not support upper lower case differentiation in the subjects.

Absolute real technical feedback is imperative to resolving this issue.

This is to consider if we should add the ability for MVAL REQ/RESP/MSG messages to support Ground Telemetry.

Perhaps Processed Telemetry could do this to, though since it is a hybrid between the unprocessed (raw) Telemetry Message and the Mnemonic Value Data Message, perhaps this doesn't make sense (is there ever a raw frame or sample for Ground TLM?).

Of note, all C2MS Messages have the following REQUIRED fields in the header:

• MISSION-ID
• CONSTELLATION-ID
• SAT-ID-PHYSICAL
• SAT-ID-LOGICAL

And in the Subject, all TLM messages have

MISSION, CONST, and SAT as required elements.

A current work-around is to use Mission, Constellation, and Satellite String values to represent something on the ground, such as an antenna, modem, gateway, etc. The question at hand is if we should make this a little more formal.

Options might be to rename the fields to something more generic than Mission, Constellation and Satellite. At issue, though, is how to capture this in a backward-compatible way.

For now, just capturing this for future discussion.

Notes on what we already say in the document:

6.2.3.2: If an element is defined as being required but is not applicable for that mission or to that specific message, "FILL" (no quotes) is placed in that element's position, meaning that it is not known or specified. For example, most but not all messages are satellite-related, so a “Satellite ID” is part of all message’s subjects. If a message is not satellite specific, "FILL" can be used in place of the "Satellite ID".

8.7 Real-time Telemetry Data Messages
Telemetry Messages are data packages that contain metrics from remote devices such as spacecraft.

In Reston, 2026, we felt it was best not to provide "ground" Telemetry for now, because we would have to 'fake-out' the system by using values other than Mission/Constellation/satellite designators in the header. Furthermore, it's unclear why we would supply ground telemetry, when GEMS performs that function already. Decision was to revisit in 2.0, when we might make the header for messages less-specifically for satellites, and more to do with Satellite Contacts.

Working with Eric, create a TLV Message that has a name-value concept to allow interoperability with external standards, for example to send a GDDI/GEMS/SNMP/SCARS message or receive one as defined with fields in that other spec.

For all data-related messages (mostly notification messages, but could be some response messages), consider adding an array as a Participant Chain... what component or resource was involved in producing the data... probably would be String for the name, a Typed Varialble, plus a time-tag. Typed Variable would allow it to be a digital signature. This has some oerlap with both Participant in TDM and Originator in NDMs.

When Boolean fields are listed in Message "Additional Information" tables, they sometimes use True/False of for the values and sometimes 0/1.

Should reduce to always use True/False.

Specific cases of the 0/1 usages:

Table 8-99. Telemetry Processed Frame Message Additional Information
Table 8-119. Mnemonic Value Response Message Additional Information
Table 8-124. Mnemonic Value Data Message Additional Information
Table 8-141. Archive Mnemonic Value Data Message Additional Information

Should the CMD Request Message have any fields to indicate if it is a restricted or sensitive command requiring special handling? I note that we have the metadata now on CMD request and maybe that takes care of it. Just capturing for discussion.

I'm putting this issue forward simply for discussion. To me, it seems unnecessary, because the command-execution system that receives the request seems like a better arbiter of whether a command is restricted, and what to do with it... but just want discussion.

In the next major revision (2.0), when backwards-compatibility is not an anchor, we need to update all Boolean fields in messages to be either required or dependent, and in the latter case to make clear what it is dependent upon.

No boolean field should be optional... They should all be present with either TRUE or FALSE values.

This is because it is ambiguous how a message receiver should interpret a non-present Boolean field. They must simply chose whether to treat it as TRUE or FALSE.

All C2MS Messages can be augmented via the CUSTOM-FIELD added in 1.2. However the C2MS Message Envelope does not have that capability.

This issue simply to evaluate if it should.

(My own feeling is 'no' because the envelope is not meant to convey any mission information, but is a generic way to handle the transport of the C2MS Message, but it should be discussed).

This issue covers the reevaluation of the GUID type to consider specifying not only the format (RFC 4122), but also the algorithm for generating the guid.

Typed Variable was added in 1.2. The field DATA-VALUE is represented in the model as just VALUE. The model needs to rename this to DATA-VALUE and the diagram for figure 6.3 needs to be updated.

In the model, Message Security (part of Message Envelop) has text under the model class->specification->documentation that is superfluous.

All such 'documentation' should only exist in notes on the diagram or as text in the spec document (until we move to a model-based spec in 2.x). For now, remove this, as it was used to capture information during development. When removing, perform an analysis to see if that text should be moved to a note on the diagram or placed in the spec document, instead. Otherwise, simply remove.

Message Security (part of Message Envelop)
"a sender-identity type (JWT/SAML) String. Note that this field could be a group.

SECURITY-CONTROL-INFO with 0 = no encryption/signing 1 = digital signature, 2 = mac, 3 = … and 7+ = Mission Defined."

In the model, a few package names don't line up exactly with the changed subsections as intended.

The following need to be changed in the model (and note that there is no change to the document itself, as it already has the desired names):

"Real-Time Telemetry Data Messages" to "Real-time Telemetry Data Messages"

"Real-Time Mnemonic Value Messages" to "Real-time Mnemonic Value Messages"

"Contact Reservation Messages" to "Satellite Contact Scheduling Messages"

"OMG Generic Service" to "OMG Generic Service Messages"

In the following cases, both the model AND the document titles need to change:

"Monitor Level Messages" to "Monitor-level Messages"

"Component To Component Transfer Messages" to "Component-to-Component Transfer Messages" (in the case of the document, drop (C2CX) from the section heading).

From Elisa during AB Review of C2MS 1.2:

“It's odd that there's only one external reference (href) to a UML primitive type in the whole model. There are several primitives masquerading as Classes in a Package called Type (line 696) which includes classes named String, Boolean etc. This is really isn’t right, and should be corrected to reference the standard UML PrimitiveTypes (which are not Classes). Some of the classes in the Type package are disguised datatypes e.g. U32. Others are odd such as "Dependent upon response" (line 729) (does not appear in the spec) and "Variable". See sect 6.3.5 of the spec which even starts with the statement that they are datatypes (not Classes). That includes the statement that Variable is deprecated but that's not indicated at all in the XMI. Typed Variable has a structure so should be a uml:Datatype not a PrimitiveType. The primitive types should be mapped to XSD types using the XMI tags”

C2MS Response at the time:

"I agree, but we have tried to maintain backwards compatibility except in cases where the prior definition is simply incorrect (and therefore unworkable). Our approach has been to live with the way C2MS 1.0 laid out data types and structures with the intent to revisit them in a 2.0 future release when backward compatibility doesn’t tie our hands. With that in mind, my recommendation is to leave this as it is in the spec and model as long as we are in the 1.x baseline. "