[Sea-sa] Meetings notes for SEA - SA, RASDS Subset meeting, 10 June 24

[Shames, Peter M (US 312B)]

Dear SEA SAWG team,

Attendees: Josiah Johnson, Ramon Krosley, Shelbun Cheng, Fred Slane, Peter Shames

Great meeting Monday, 10 June 24, so glad to have your participation.  The focus was largely on the proposed new work item, the refresh of the Reference Architecture for Space Information Management (RASIM), CCSDS 312.0-G-1.

Further work on RASDSv2 will be delayed until after the results of the Agency review have been returned.

General notes from the telecon:

  1.  Peter has shifted to working 1/2 time, but will continue to lead the SE Area and the SAWG.  A certain amount of effort will go into mentoring replacements.
  2.  RASDSv2 has passed CESG review for release to Agency Review and is in the CCSDS CTE queue being prepped for that.  We discussed the review and approval flow for RASDS so that the team knows what to expect.
  3.  We discussed the overall CCSDS document creation and review process flow for those who are new to this work.
  4.  We discussed the specifics of the review and approval flow for the RASDSv2 document, which is to be published eventually as a joint CCSDS and ISO TC20/SC14 document, would occur.  We also touched on the few other CCSDS documents that have such shared “ownership”, such as the MOIMS Nav WG CDM (SC14) and SM&C WG XTCE (OMG), and the SIS DTN BPv7 (IETF).
  5.  We spent much of the remainder of the time discussing the proposed set of RASIM mods

Mods proposed for the Reference Architecture for Space Information Management (RASIM), CCSDS 312.0-G-1

  1.  Josiah Johnson had agreed to be the lead editor for this document and he has approval of his organization to do this work.
  2.  Josiah mentioned the shift over time from client / server architectures to web based, and from that to web services using HTTP(S) and to other deployment modes.
  3.  We discussed the continuing evolution to virtualized / containerized / cloud deployments. In the context of fig 4-5 and 4-6 (attached, with annotations).
  4.  We agreed that these kinds of web service aspects can best be modelled as aspects of where instantiations of user or service applications are deployed (thin or thick clients, or web browser clients), and of which technologies are adopted for the messaging middleware.
  5.  The same kind of analysis led to a belief that virtual and cloud deployments can similarly be treated as aspects of how instantiations of user or service applications are deployed, on local servers or in some virtual or containerized environment.
  6.  We agreed that the topics of hypervisor or orchestration can best be addressed by considering those as “on the side” functions, separate from the stack itself, that monitor and manage the environment and the deployments.  This is shown as a “cross cutting” orange “management” box to the left side of the existing stack.
  7.  Similarly, various security considerations may be modelled as a different kind of cross cutting functions, shown as a red “security” box on the right side of the existing stack.
  8.  The possibility of hybrid architectures was also briefly discussed.  The assumption being that different parts of the extended system would evolve at different rates, or adopt architecture features, driven by local choices or available resources, especially with space deployments.  The possibility of deployments of something that might be described as a “private cloud” being deployed in a space habitat context was proposed, or of various distributed servers.  This all warrants much more discussion.

  *   We agreed to consider inclusion of a new “Deployment Section” that would show various abstract versions of these different deployment approaches.  This is TBD.
  *   We agreed to consider inclusion of one or more deployment options that would be suitable for Lunar (and future Mars) environments.  This is TBD.
  *   We agreed to use a PPT file, with a combination of text (intended to address new topics in the document) and drawings (intended to become figures in the revised document).   We used this approach with RASDSv2 and it was very effective.
  *   We agreed to consider how trade studies and cost considerations might be addressed in the updated document.
Action Items:

  *   Team: review these notes and propose any changes, updates, or edits
  *   Josiah: create a PPT file and use it to propose how to include these edits, or not, into the next revision of RASIM
  *   Fred: propose to SC14 the adoption of RASIM as a companion document and see if one or more of the SC14 leads might join the group and actively contribute
  *   Peter: reach out to Dan Crichton and to members of the existing MOIMS DAI WG to see if they are interested in either active participation or direct involvement
See you all next month.

Best regards, Peter


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20240612/49967674/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RASIM Fig 4-5 notes.pdf
Type: application/pdf
Size: 275754 bytes
Desc: RASIM Fig 4-5 notes.pdf
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20240612/49967674/attachment-0002.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RASIM Fig 4-6 notes.pdf
Type: application/pdf
Size: 200632 bytes
Desc: RASIM Fig 4-6 notes.pdf
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20240612/49967674/attachment-0003.pdf>