[Sea-sa] RID processing for RASDSv2 Agency Review. Initial dispositions.

[Shames, Peter M (US 312B)]

Dear SEA SAWG team,

Attendees: Josiah Johnson, Shelbun Cheng, Fred Slane, Christian Stangl, Dan Crichton, Peter Shames

Thanks for the great meeting Monday, 9 Sep 24.  The focus was entirely on reviewing the RIDs that resulted from the Agency Review of the Reference Architecture for Space Data Systems (RASDv2), CCSDS 311.0-P-1.1, June 2024.

The outcome of this meeting was to generate responses to all of the submitted RIDs.  Many of these were editorial, and easily dispositioned.   The several that needed further discussion were all dispositioned by the WG during this Telecon.  Updated RID forms will be created (where needed) and the responses sent to the originators for concurrence.

Since none of these RIDs raised significant issues, once the originators concur with the proposed dispositions of those that were submitted we assume that the revised document will be submitted to the CESG and CMC for approval to publish.

Feedback and corrections on these notes is hereby solicited from those who were present.

Notes from the telecon:

RID Discussion

  *   Craig Biggerstaff, JSC-04: “Consider limiting the colors for physical nodes to those from Figure 3-1”.  After considering the RID and the source of confusion, the WG agreed to remove the confusing color codes, which came from the SCCS-ARD, but are not relevant in RASDSv2, from Fig 3-1.  The existing text in Sec 2, for Fig 2-3 and 204 already makes the point about the only defined color codes and where they are used in object and ontology diagrams.  All other color choices, specifically in example diagrams, have no relevance nor expected consistency.
  *   Marc Blanchet, email - SANA: The SANA is already included, as a CCSDS relevant example of a registry, in Sec 5.8, Examples of space information management infrastructure.  No further references to SANA are appropriate in this architecture methodology document, and it is covered, separately, in the SCCS-ARD, where implementation issues are appropriate.
  *   Marc Blanchet, email – Bp/IP: The issues that are raised, which are relevant implementation and performance considerations for IP and BP  routers are not relevant in this reference architecture context.  No further references to IP and BP are appropriate in this architecture methodology document, and these topics may be covered, separately, in the SCCS-ARD, where implementation issues are appropriate.
  *   Conrad Bock, email – Arcadia:  Conrad pointed out an existing MBSE framework, Arcadia / Capella, that is an open source MBSE tools suite operating within the Eclipse framework.  Upon examination this touches on many, but not all, of the RASDSv2 viewpoints, and has a similar set of object definitions and relationships.  It misses several RASDS viewpoints (connectivity, protocols, structures, information) and did not adopt the IEEE 42010 correspondence concepts nor the rigor we have added with the object / ontology approach.  After discussion we agreed to include a reference to Arcadia/Capella, and one to an earlier RM-ODP MBSE effort, as applicable references in Annex C, where MBSE is addressed.
  *   William Ferguson, email – security / assurance: William proposed shifting the security topics in each viewpoint to address assurance, and incorporating discussion of various NIST/ISO controls.   After discussion we agreed to add mission assurance as an Enterprise topic and include a reference to the Sec WG Security Architecture document.  The recommendation to the Sec WG is that they give due consideration to these topics in the Security Architecture document revision that is in planning.  Addressing how to deal with mission assurance in this document is out of scope.
  *   Christian Stangl, DLR-007 – move “Koki diagram”, fig 13-1 up to Sec 2:  This was discussed at some length.  All agreed that the “Koki diagram” was useful, and that the concept of being able to extend the baseline set of viewpoints was important.  But the logical flow in Sec 2 is all about introducing the viewpoints, objects, and views that RASDS defines, and the concern was that adding this rather more advanced topic would interrupt the flow.  We agreed to add a forward reference to Sec 13, where making new VP was described, in Sec 2.4.  We do want to make it clear that this is an extensible approach, but without interrupting the logical flow of the document.
  *   Christian Stangl, DLR-several:  A variety of different issues were raised regarding consistency in the naming of document subsections, specific definitions, and the handling of figures.  These are editorial in nature and will be addressed during final document editing.
  *   JAXA, INPE, and ISO TC20/SC14: All three of these organizations explicitly reported no RID input.

Definitions

  *   Craig Biggerstaff, JSC-01: There are a few places where acronyms are used without first being spelled out.  These should be remedied.
  *   Christian Stangl, DLR-003:  There are places where terms are used but not defined.  A specific one was the word “shim” in Sec 9.5.3.  There may be others and a scan will be made of the document to seek these out.
  *   Christian Stangl, DLR-012:  There are instances in the document where the word “type” is used in reference to “function type”, as opposed to “data type”, but the qualifier is left off.  This can be confusing and such instances will be found and fixed.

Kudos

  *   William Ferguson, email: “I love this version of the document …”. “Again, the document is fantastic, I loved reviewing what I could, and my feedback is based on my limited work in this area.”
  *   Fred Slane, email: TC20/SC14 reported that they are already using RASDSv2, even in its draft form, to produce their Systems and Operations ADD.  “This is going to be an important concept for the SC14 mindset.“  They expect to adopt the final version, in its ISO “coverpage” form, within TC20/SC14.
  *   Christian Stangl, verbal: Reported that the reviewers, while they had a number of comments, really liked this version of the document.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20240909/93d2cce5/attachment-0001.htm>