[Moims-dai] FW: [EXTERNAL] CESG Polls - responses from MOIMS-DAI

Tue Oct 22 11:05:55 UTC 2024

I hope we can discuss the following in today’s meeting.

In an effort to seek a resolution with Peter I asked him for examples of actual usage of RASDS. He provided these – my comments below. I’m not sure these show a very wide adoption of RASDS, nor are the examples particularly helpful to me. I would be interested in the views of others.

I note that in section 2.3.2.2 of CCSDS A02.1-Y-4, CCSDS ORGANIZATION AND PROCESSES Organization and Processes for the Consultative Committee for Space Data Systems <https://public.ccsds.org/Pubs/A02x1y4c2.pdf>  it states that:

b) Consensus. The entire CCSDS technical organization is run by a process of 

consensus, and it is the CESG that decides if the standardization process has come up 

with a result that reflects a real consensus. Consensus does not necessarily mean that 

unanimous agreement has been reached, but that the result incorporates the best set of 

compromises that all parties can agree to. The principle of consensus applies to all 

decisions made at the CESG level. (See 5.1.2 for a discussion of consensus.) 

Working Groups must demonstrate that consensus processes were followed when 

drafting documents. The entire CESG must review each CCSDS document prior to its 

entering a track, and CESG consensus is required before that document can move 

forward. One of the main reasons that the CESG might block something is that the 

WG was unable to show that true consensus was reached or that the result did not 

really gain consensus in the CCSDS as a whole, that is, among all of the WGs in all 

Areas. For instance, the result of one WG might clash with a technology developed in 

another, or an AD might try to force through a “pet project” that has a negative effect 

on the rest of the CCSDS capability suite. 

 In the event that the process of reaching consensus was unusually contentious at 

either the WG or CESG level, the CESG chairman shall raise the proposed outcome 

for review by the CMC before making a final determination.

…….

The chair of CESG is Klaus-Juergen Schulz.

From: Shames, Peter M (US 9740) <peter.m.shames at jpl.nasa.gov> 
Sent: 22 October 2024 01:51
To: David Giaretta <david at giaretta.org>
Cc: Thomas Gannett <thomas.gannett at tgannett.net>
Subject: Re: [EXTERNAL] CESG Polls - responses from MOIMS-DAI

Hi David,

Sure thing.  There are three primary documents that make extensive use and several others that adopted RASDS:

CSS/SEA: SCCS-ARD, CCSDS 901.1-M-1, Cross Support reference architecture requirements (only a few diagrams, now being updated)  (2015)

CSS/SEA: SCCS-ADD, CCSDS 901.0-G-1, Cross Support reference architecture description (many SLS, SIS, CSS, and SEA diagrams) (2013)

CSS: FRM, CCSDS 901.3-M-1, Functional Resource Model (a number of function diagrams that use RASDS concepts)  (2024)

These are all 901, from CSS plus SEA

In 901.3-M-1, not clear what “use RASDS concepts” means

SEA: ASL, CCSDS 371.0-G-1, Application and Support Layer (ASL) architecture document (many MOIMS & SOIS diagrams including a set for DAI)  (2020)

4.2.9 contains DATA STORAGE AND ARCHIVING which contains

I did not see a set of DAI diagrams. Perhaps others can find some more.

SEA/Sec WG: Security Architecture, CCSDS 351.0-M-1, security for space systems (a number of different views aligned with RASDS)  (2015)

Not sure what “aligned with” means

MOIMS: MO Services, CCSDS 520.0-G-3, Mission Operations Services Concept (a number of MOIMS service & protocol diagrams using RASDS)  (2010)

SOIS/Wireless WG: SOIS high rate comms, CCSDS 883.0-M-1, High data rate wifi & 3GPP comms (end to end network protocol diagrams) (2024)

Could not find CCSDS 883.0-M-1. I think this may refer to CCSDS 883.0-B-2        Spacecraft Onboard Interface Services-High Data Rate Wireless Proximity Network Communications, but this does not refer to RASDS

Cheers, Peter

From: David Giaretta <david at giaretta.org <mailto:david at giaretta.org> >
Date: Monday, October 21, 2024 at 3:13 PM
To: Shames, Peter M (US 9740) <peter.m.shames at jpl.nasa.gov <mailto:peter.m.shames at jpl.nasa.gov> >
Cc: Thomas Gannett <thomas.gannett at tgannett.net <mailto:thomas.gannett at tgannett.net> >
Subject: Re: [EXTERNAL] CESG Polls - responses from MOIMS-DAI

Hi Peter

I'd be grateful if you could you point me at the CCSDS books which use RASDS so that we can see what it looks like when in actual use, rather than in the examples in the RASDS book.

..David

Sent from Outlook for Android <https://urldefense.us/v3/__https:/aka.ms/AAb9ysg__;!!PvBDto6Hs4WbVuu7!IAKcUcoB8efDCQ9d8dzI9YVefWNEzgj_k5xtDAyjfwnscKH2IKeHKsISuRHDRjNdRTCdcpM-9b8VFIe-cyviWO2-$> 

  _____  

From: Shames, Peter M (US 9740) <peter.m.shames at jpl.nasa.gov <mailto:peter.m.shames at jpl.nasa.gov> >
Sent: Monday, October 21, 2024 10:15:33 pm
To: david at giaretta.org <mailto:david at giaretta.org>  <david at giaretta.org <mailto:david at giaretta.org> >
Cc: Thomas Gannett <thomas.gannett at tgannett.net <mailto:thomas.gannett at tgannett.net> >
Subject: Re: [EXTERNAL] CESG Polls - responses from MOIMS-DAI

Hi David,

Your replies do not surprise me, but they are a bit disappointing.    I do realize that you are, to a great extent, trying to address a community that is outside the space agencies that make up CCSDS membership, and that you have great acceptance with those Library folk.  That’s wonderful.  But I think it’s also important to keep in mind that these documents are being published as CCSDS documents.  Accordingly I believe that they should align with other CCSDS document, and support CCSDS requirements and practices.  The issues that I raised, in both cases, go beyond the cosmetic.

OAIS is used by space agencies, including ESA, NASA (e.g. NSSDC and JPL), and CNES. It is also used as the reference best practice for all commercial and open source archival software systems, which are used throughout the world, including EU, UN, World Bank, ad well as national archives in many countries. And of course a number of libraries.

I raised an issue with how you handled PMBOK and DMBOK in the draft 653.0-M-1 document.  I will point out that we do have a similar issue with RASDS itself which is explicitly focused on its ability to support the documentation and understanding of space data systems architectures, but the methods do have broader applicability than that and have been adopted in other venues.   In a related fashion, somewhat like your references to PMBOK and DMBOK in 653.0-M-1, we reference ISO 42010.   We do explicitly adopt 42010 as a meta-meta-model, so this is addressed explicitly where it must be for background and understanding of the concepts of metamodel levels, an important aspect of this whole framework from the outset.   The details of all of that are in a RASDS Annex.

I do not think that you have the same relationship to PMBOK and DMBOK, but I may misunderstand the intent.  As I initially commented but maybe not clearly enough, you seem to have sprinkled these concepts in several places in the document.  You take the time to explain, also in several places in the body of the document, that they are similar but different and that in some cases you have adopted one, or the other, or some totally new term.  My recommendation is that you move all of that discussion into the existing Annex B, and that you resolve all of the terminology issues there, in the Annex.  Then you can point at that Annex at the front of this document, and name the sources, but only use the agreed set of terms in the body of the document without having to explain in each section why you chose one and not the other.  It will make for a much cleaner and clearer presentation of the concepts that you really want to promote.

In the matter of the rather confusing collection of diagram styles used in CCSDS 650.0-M-3, I do understand that you would prefer to not change these diagrams, and that you wish to continue to defer fixing them to some indefinite point in the future.   I am, at this point, reluctant to accept that again.  This issue of diagram styles, formats, and clarity was brought up before, back in 2019 (see attached RIDs), and it was similarly brushed aside.  It remains an internal issue within the document and an issue within other related CCSDS documents.   

There have been opportunities to fix this issue which were not utilized.  In fact, upon further examination, I find that these diagrams have been worked on by the DAI WG, and changed into somewhat different styles over the years (see 3 attachments of Fig 4-1).  Three different “flavors” have been adopted, none of them self consistent within the document and none of them aligned with any formal method.  Apparently there was the energy to edit many of these figures, but not to change them to be either self-consistent within the document nor compliant with recommended practice.

I think you will find that there are some similarly simple set of object transformations to what you have done before, that will not require redrawing everything, but will bring the diagrams into alignment with RASDS AND create internal consistency within the document and with other, related, documents.   

I’d like to see that change made now.  Since your community has been able to accept all of these other changes over time I suspect that they will accept this change as well.  

Heck, I’d even be willing to help.

Regards, Peter

From: david at giaretta.org <mailto:david at giaretta.org>  <david at giaretta.org <mailto:david at giaretta.org> >
Date: Monday, October 21, 2024 at 3:26 AM
To: Shames, Peter M (US 9740) <peter.m.shames at jpl.nasa.gov <mailto:peter.m.shames at jpl.nasa.gov> >
Cc: Thomas Gannett <thomas.gannett at tgannett.net <mailto:thomas.gannett at tgannett.net> >
Subject: [EXTERNAL] CESG Polls - responses from MOIMS-DAI

Dear Peter

Here are the MOIMS-DAI responses to your conditions.

Please let us know is our proposals address these adequately.

Regards

..David

Chair, MOIMS-DAI

CESG E-Poll Identifier:  CESG-P-2024-09-004 Approval to publish CCSDS 653.0-M-1, Information Preparation to Enable Long Term Use (Magenta Book, Issue 1)

     Peter Shames (Approve with Conditions):  Overall I like the document and think it conveys the concepts quite clearly.  There are a couple of terms (CRIS and GDPR) that are named, but never clearly defined nor tied to any specific source.  I am fairly certain that CRIS does not mean Construction Risk and Insurance Specialist nor Certified Release of Information Specialist.  The introduction of PMBOK and DMBOK is very useful, but it would be better just handled in Annex B and not scattered repetitively in the document.  Strongly recommend defining your terms clearly and moving on.  The choice of the term "Collection Groups" instead of something like "Process Groups" seems a little peculiar and bothersome.  They are, after all, ""processes and not ""collections.  It may be a pain, but I would recommend re-thinking this choice of terms now.

MOIMS-DAI PROPOSAL  <https://urldefense.us/v3/__http:/review.oais.info/show_bug.cgi?id=394__;!!PvBDto6Hs4WbVuu7!OYv0NDiPNOY-iJo-iFVGKXpvN7sRiV74GTVUca26WxN0Bjm1NfgX95gl4WwZ0IxylvJjHqk2txNtDwDqYTDkPmCY$> http://review.oais.info/show_bug.cgi?id=394

1) We note that CRIS and GDPR are in Acronym list.

However, we propose adding the expansion of the acronyms at 1st occurrence see section 4.2.3.4 and 4.2.3. Ok

2) We disagree. PMBOK/DMBOK is mentioned briefly in the introduction and then in detail in sections 2.1 and 2.2, as examples of related best practice to justify our approach, which we do not think can be described as “scattered repetitively in the document”.  Issue still exists.  These two docs, and their terms, appear in several places, repetitively.  And then there is a whole section, Annex B, that talks about both of them and their different uses of terms.  This document would be better served by using Annex B to sort out the terms and define the set you are going to use, once.  Then you can introduce these sources, once, in the beginning, use the terms you define in Annex B throughout, consistently, without continually having to describe these two sources and how they differ.  These then become your IPELTU terms instead of always referring to them as “PMBOK does this and DMBOK does that”.  This would be much clearer for everyone and still acknowledged the source from which they were derived.

3) We disagree. Section 2.1.2 justifies the use of the term “Collection Group” - this is about information that is to be collected - not the processes.  On the contrary, your own text in sec 2.1.2 describes these as “types of activities” and says “including ‘Closing’ because when the process to create data closes, steps must be taken to ensure its usability after the end of that process ”.  These processes and activities are about managing data collections, but they are not, themselves, data collections.   I think it is a misleading choice of terms.

CESG E-Poll Identifier:  CESG-P-2024-09-001 Approval to publish CCSDS 650.0-M-3, Reference Model for an Open Archival Information System (OAIS) (Magenta Book, Issue 3)

     Peter Shames (Approve with Conditions):  

Vote 2) Request that the document adopt RASDS architecture documentation style in all diagrams.  The current set of diagrams is unclear and it is easy to confuse different kinds of rounded, clipped, burnished, objects.  Furthermore, the diagramming styles adopted are not even consistently used throughout the document.  Compare "information objects" shown in Figs 2-3 & 2-4 with those shown in sec 4.  This would bring this document into line with a number of other CCSDS documents, including the ASL which covers this same material at an overview level.

Vote 1) This is an issue that has been raised before and never satisfactorily resolved.  While there has clearly been some amount of attention paid to the diagrams used in this document they remain, to my eyes, inadequate, unclear, and inconsistent.  The use of nearly identical rounded, elongated, clippped corner objects to distinguish systems, functions, and organizations is unclear.  We now have a significant body of CCSDS documents that have successfully used RASDS to create diagrams that represent all of these same kinds of concepts (and more).  I can see no good reason, aside from the modest amount of time needed, for this document not to be brought in line with those conventions.  The results would be both alignment with the rest of these CCSDS documents, at least one of which references this same subject, and more importantly, increased clarity.  In addition, the document itself is internally inconsistent, since it uses at least three different drawing styles to represent "information".  Compare the "information objects" in figures 2-2, 2-3 (what are those brown things?), and the information objects modeled using UML in sec 4.3.1.  If more effort were put into consistent use of a standard representation, and less into creating "pillowy" shaded objects, the document would be much improved.

MOIMS-DAI PROPOSAL  <https://urldefense.us/v3/__http:/review.oais.info/show_bug.cgi?id=396__;!!PvBDto6Hs4WbVuu7!OYv0NDiPNOY-iJo-iFVGKXpvN7sRiV74GTVUca26WxN0Bjm1NfgX95gl4WwZ0IxylvJjHqk2txNtDwDqYTWt1dGR$> http://review.oais.info/show_bug.cgi?id=396

Vote 2) 

We do not this the request is reasonable. Section 2 diagrams were designed to be informal, to explain the concepts. These concepts are then made more formal in section 4. This is stated in section 2.1 as follows:

"The purpose of this section is to motivate and describe several key high-level OAIS concepts. A more complete view, and a formal modeling of these concepts, is given in section 4."  

There is nothing in RASDS that would prevent you from creating clear, simple, diagrams that would align with recommended practices and provide clearer, internally consistent, diagrams.  And the alignment with UML information modeling, which is also adopted in RASDS, would be preserved.  Speaking of which, isn’t UML normative given how it is used in the document?  And note that UML, and your own Annex C, use simple rectangles and not shaded curvy ones.

Vote 1) 

Peter says the diagrams are "inadequate, unclear, and inconsistent." Yet they have been in place, largely unchanged, for more than 20 years, and are widely used and well understood. Also, this is a magenta book, not meant to be implementable.

We disagree with Peter when he says "I can see no good reason, aside from the modest amount of time needed, for this document not to be brought in line with those conventions". DAI believes that this will take a significant amount of time to make all the required changes of diagrams and associated text in the document, and such extensive changes would (1) confuse the current very large set of users and (2) would further delay the publication by requiring another round of CCSDS and ISO reviews.

We will consider changes in the diagrams for the next review cycle.

See attached versions of these diagrams that have, in fact, been changed over the years, but were not yet brought into either internal alignment nor aligned with other CCSDS documents that relate to the same set of topics.  This issue has been around for years, changes were requested five years ago, and the diagrams have now been changed, at least twice, without bothering to align them internally or with other CCSDS documents.  Let’s fix this now.

Please let us know is these proposals address your concerns adequately.

Regards

..David

Chair, MOIMS-DAI

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20241022/b9175540/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 129732 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20241022/b9175540/attachment-0001.png>