Command and Control Message Specification Avatar
  1. OMG Specification

Command and Control Message Specification — Open Issues

  • Acronym: C2MS
  • Issues Count: 6
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Add documentation within the model

  • Key: C2MS11-13
  • Status: open  
  • Source: Braxton Technologies, LLC ( Gerry Simon)
  • Summary:

    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.

  • Reported: C2MS 1.0a1 — Wed, 12 Dec 2018 21:31 GMT
  • Updated: Fri, 21 Jun 2024 18:15 GMT

Add documentation within the model

  • Key: C2MS12-7
  • Status: open  
  • Source: Braxton Technologies, LLC ( Gerry Simon)
  • Summary:

    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.

  • Reported: C2MS 1.0a1 — Wed, 12 Dec 2018 21:31 GMT
  • Updated: Fri, 21 Jun 2024 18:15 GMT

Lack of a registry concept

  • Key: C2MS11-1
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    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.
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:10 GMT
  • Updated: Fri, 21 Jun 2024 18:13 GMT

C2CX Heartbeat comments

  • Key: C2MS11-2
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    (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
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:21 GMT
  • Updated: Fri, 21 Jun 2024 18:13 GMT
  • Attachments:

Archive Mnemonic Value Request comments

  • Key: C2MS11-3
  • Status: open  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    (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.

  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:25 GMT
  • Updated: Fri, 21 Jun 2024 18:13 GMT

Specify multiplicity for required and optional fields