In the current version of the model, there is no descriptive documentation within the model itself. This could be easily added from the non-normative specification and would aid engineering teams who use the model.

This will be OBE when we move to a model-based specification

At present, the model is used only for diagrams and is otherwise non-normative. The specification document contains all the detail. In the future, we will move to a model-based specification. There is no need to add documentation to the model until that time and it would cause documentation duplication.

Set the association multiplicity for required fields to '1' and optional fields to '0..1'

Documentation Change to be Made in 1.1

The following changes will be made:

• Make changes to Section 8 PIM – Message Definitions under Field Name to clarify the notation used for "series".
  
  
  • Add a diagram to illustrate the text
    
    
• Make changes to Section 8 PIM – Message Definitions under Required, Optional, Dependent and Tracking to clarify how R/O/D are used and to separate out Tracking since that does not indicate R/O/D.
  
  
  • Add a diagram to illustrate the text
    
    

Make global changes as represented below:

• Make changes to all Message Diagrams, beginning with Figure 8-2. Message Header Diagram and ending with Figure 8-40. Tracking Data Message Diagram to show multiplicity of each attribute. Note that we no longer need the concept of a block called "Required Fields" and another called "Optional Fields". Additionally, each changed diagram will use fields in the same order as found in the "Additional Information" table for the message to improve readability.
  • This is illustrated in the attached before and after diagrams for the following, each showing a slightly different aspect of the changes:
    • the Directive Response Message
    • the Configuration Status Message
    • the Heartbeat Message
    • the Mnemonic Value Request Message
  • The identical pattern will be applied across all the above mentioned figures. Note that the 'revised' diagrams already show changes previously approved from C2MS11-18 (making all messages subclass C2MS Message which contains a Header) and C2MS11-31 (Clarify the UML diagrams regarding the values for the fields inherited from Message Header).
    
    
• Make changes to all Message "Additional Information" tables, beginning with Table 8-3. Message Header Additional Information and ending with Figure 8-40. Tracking Data Message Diagram to show multiplicity of each attribute. This will verify that all tracking fields are described in the tables clearly.
  • This is illustrated in the "revised text" of this issue with table changes for the same four messages listed above, again, each showing a slightly different aspect of the changes. The identical pattern will be applied across all the above mentioned figures.
    
    
• This proposal constitutes a plan to do the above if voted on, though there will be a follow-on vote with a separate issue/proposal to show all the changes before and after for completeness. Vote 'yes' on this one if you plan to vote 'yes' on the final (to avoid extensive work without commitment).

• If this proposal is accepted, a complete set of before and after images will be provided as part a second issue/proposal and if accepted will be provided as part of the RTF Report assuming that second issue/proposal is accepted.
  • Note that the final images may be a convergence with other voted in global figure changes, such as (but not limited to) C2MS11-18. In other words, if this proposal is accepted and others like C2MS11-18 the proposals are also accepted, all sets of changes will be made in the final "after" images in the RTF Report.

(Archive Mnemonic Value Request) Section 8.9.1

• Need official registry for FORMAT values

The AMVR message has a field called FORMAT that is of type String, but there is no enumeration of possible formats. This could be handled by requestor and supplier agree on a format.

FORMAT is used to define the file format of the return data.

Clarify FORMAT field of AMVAL Request Message

Change the "notes" relating to FORMAT of the message to indicate, similar to SPECIAL-INFO field in Directive Request Message, that this is "For application use".

(C2CX Heartbeat) Section 8.5.4

• Suggest not having CPU / Memory utilization in the messages. That would be better implemented through normal system monitoring mechanisms (e.g., SNMP). Code to retrieve such information is typically platform-specific and is not related to the business logic of the component.
• If such information is required, suggest having a system monitoring component instead.
• Unclear exactly how this would work in a clustered environment. Different hosts implementing the same service would provide conflicting answers.
• Unclear why the commentary on why memory leaks are bad is in the spec

Field and Text Changes to Heartbeat Message

Following changes to be made:

1. Remove CPU / Memory utilization in the messages
2. Replace Heartbeat Message Diagram
3. Remove text about memory leaks

See C2MS11-2 for rationale.

See attachments for original and revised figure, Figure 8-11. Heartbeat Message Diagram

Note: There had been discussion about whether it would be OK to remove fields from the spec. At a 2022 C2MS RTF Meeting, Jay was good with removing the fields.

Discoverability of data is still a major concern due to the lack of a registry.

• Unclear how components are supposed to find out about available resources
• Unclear how components are supposed to find out about related subjects
• What is the associated heartbeat subject of a client, particularly a temporary one?
• ME1 depends on knowing the name of the other end beforehand. Where is this supposed to come from and why should a component have to care about that?
• Recommend a registry be considered and answers to question above.

Part of a TBD Sister Spec

This may be useful for "offline" data sharing services. Probably not for realtime operations on the floor. ... but probably not within scope of C2MS, because this spec defines the message set, not how they are used.

In the current version of the model, there is no descriptive documentation within the model itself. This could be easily added from the non-normative specification and would aid engineering teams who use the model.

Defer to later version when process is clear

Until we have a way to generate the doc from the model, we don't want to duplicate or create copy-paste issues or especially to become inconsistent between the document and the model documentation. The RTF meeting in June 2022 determined to defer it.

Set the association multiplicity for required fields to '1' and optional fields to '0..1'

Defer to FTF 1.1

Received after RFC 4-week deadline.

In the current version of the model, there is no descriptive documentation within the model itself. This could be easily added from the non-normative specification and would aid engineering teams who use the model.

Defer to FTF 1.1 (But good idea)

Issue received after the RFC 4 week deadline.

(Archive Mnemonic Value Request) Section 7.9.1

• Need official registry for FORMAT values

This issue is out of scope of FTF type of work.

Recommend that this issue be deferred to C2MS ver 1.1.

(C2CX Heartbeat) Section 7.5.4

• Suggest not having CPU / Memory utilization in the messages. That would be better implemented through normal system monitoring mechanisms (e.g., SNMP). Code to retrieve such information is typically platform-specific and is not related to the business logic of the component.
• If such information is required, suggest having a system monitoring component instead.
• Unclear exactly how this would work in a clustered environment. Different hosts implementing the same service would provide conflicting answers.
• Unclear why the commentary on why memory leaks are bad is in the spec

Not necessary for now - fields are optional

Referenced fields in HB are optional, so not necessary to use them. And others have indicated the comment re: memory leaks is useful. SDTF Ottawa recommended deferring until next update cycle, i.e., Ver 1.1.

Discoverability of data is still a major concern due to the lack of a registry.

• Unclear how components are supposed to find out about available resources
• Unclear how components are supposed to find out about related subjects
• What is the associated heartbeat subject of a client, particularly a temporary one?
• ME1 depends on knowing the name of the other end beforehand. Where is this supposed to come from and why should a component have to care about that?
• Recommend a registry be considered and answers to question above.

*This issue is out of scope of FTF type of work. *

Recommend that this issue be deferred.

A potential workaround is that Heartbeat messages be used to discover other components/services.

(Product Messages) Section 7.11 (Though these comments are related to guidance for custom messages

• Consider providing guidance regarding what the minimal set of attributes should be for a custom message type.
• Indicate that custom messages can be considered to become sponsored message types in future versions of the specification.
• Extending the lexicon should be encouraged by the implementation, not discouraged, as the strictest of the GMSEC 4.x MIST modes does.

Change section 8.1 to mention extensions

Change: "The Message Header is a super-class for all C2MS messages in the sense that all fields in the Message Header appear in all of the C2MS messages." to "The Message Header is a super-class for all C2MS messages and any extensions in the sense that all fields in the Message Header appear in all of the C2MS messages.

(Mnemonic Value Request) Section 7.8.1

• In GMSEC, re-requesting on the same name is (per an e-mail thread with GSFC) defined as replacing the previous subscription instead of being additive/subtractive. Is that notion being kept in this spec? If so, this should be explicitly defined in the specification.
• DURATION: When there is no DURATION specified, but a component decides to have a maximum duration anyway, data will arbitrarily stop. This is problematic for subscriptions by a non-UI system component, like a script that checks telemetry values or a roll-up / derived capability that subscribes to data to produce second-level data. Mechanisms to avoid such stoppages in data, such as periodically resubscribing are wasteful and potentially inconsistent between components.

Part covered by issue 8, DURATION issue to be fixed by adding final message

Rerequesting will be solved by resolution to issue 8, request-id. Duration will be solved by adding paragraph near duration description that final-message flag should always be set on sending final message. At the very end of section 8.8.1.3, where self-imposed duration is discussed, add this: "If a data provider does self-impose a maximum duration, the FINAL-MESSAGE field should be set appropriately in the last message sent."

• (Directive Request) Section 7.4.1

• Note that directive strings are highly vendor-specific
• There needs to be a unique ID that is set by the directive requester, not just the API. Otherwise, retrying is not deterministic. (Maybe the other side got the first directive. Maybe it didn’t. Sending the same request twice when the first was received might be dangerous.)
• Table 8-3: UNIQUE-ID is filled in by the transport/bus layer, not the user application, so this does not remove the need for correlation IDs

*Add field REQUEST-ID to all REQ, RESP, and applicable MSG messages *

Field is set by requestor and echo'd by responder in RESP and MSG messages. Same Request-ID will mean replacement, else, new request.

Added field REQUEST-ID to all REQ messages. Field is: Required, U16, "ID to identify the request message – if different request messages have the same value, the request is a replacement; else, it is a new request."

Added field REQUEST-ID to all RESP messages. Field is: Required, U16, "This field’s value is to be the same as the REQUEST-ID in the associated REQ message."

Added field REQUEST-ID to the MSG messages that have associated REQ and RESP messages. Field is: Required, U16, "This field’s value is to be the same as the REQUEST-ID in the associated REQ message."

Table 8-1: Suggest changing comments regarding signed types. As written, they read like signed magnitude, even though the range implies twos complement.

Change verbiage on I16, I32 and I64 in the types table 8-1

In Table 8-1, Field Type Definitions, make 3 changes removing the following phrase "composed of [15, 31, 63] bits for the number and 1 bit for the sign" from the I16, I32, and I64 rows.

Suggest favoring having required attributes in the messages rather than encouraging applications to hardcode looking for the nth element of the subject, as different existing GMSEC-based systems already have different numbers of tokens in the subject.

• While these items may exist in the body of a message, it has been found that some existing GMSEC consuming apps are extracting from subjects

Add verbiage re: required attributes in messages; move CONSTELLATION-ID, and the 2 SAT-IDs to Required Fields

In Figure 8-3 (Message Header), move CONSTELLATION-ID, and the 2 SAT-IDs to Required Fields.
Edit paragraph 8.1.1 to change "Some of the elements of the C2MS subject name can be made up from fields in the C2MS Message Header." to "All of the elements of the C2MS subject name can be made up from required fields in the C2MS Message Header."

Table 6-9: Acknowledge Final Status is not deterministic (rather than Yes). It is a final status in MEP2, but not a final status in MEP 4, 5

Remove table from specification

The table referenced is confusing and not needed.
It's table 6-9 in the MCMS pdf (which is what this issue was created against).
In the Beta 1 spec pdf (dtc/2018-07-01) it's on page 21 as table 0-2.

Subject naming still missing the concept of something not being directly tied to a satellite. CC2/EGS has the MISSION==ENTERPRISE, CONSTELLATION==SERVICE concept.

• Should more generic attribute names for these positions be considered?

*The existing fields Domain1 and Domain2 in the header portion satisfy this comment. *

The Domain1 and Domain2 fields already present in C2MS are intended for the purpose described in this issue. Therefore, no change needed.

Being that C2MS is standardizing the XML representation of a message entering the API, should the constructor that takes an XML-formatted Message be deemed the preferred way of using GMSEC going forward?

This issue is against the GMSEC API, not C2MS

This issue does not affect the C2MS document.

Also, the C2MS document is not standardizing the XML representation of messages; XML files are provided by the GMSEC team as a convenience, but are not part of the standard.

GMSEC uses a different value for Subject Standard Specification (in table 6.4). Expecting that GMSEC will change to use C2MS as its value to be a compliant PSM.

This comment is towards the GMSEC implementation, not C2MS

The GMSEC implementation supports either C2MS or GMSEC as the SPECIFICATION, but this does not affect the C2MS document. Therefore, no change needed.