[Moims-sc] FW: [EXTERNAL] Comments on the MAL BB

Thu Jul 7 13:24:15 UTC 2022

Dear WG members,

FYI and to be discussed.

Regards
Mehran

From: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>
Date: Wednesday, 6 July 2022 at 00:49
To: Mehran Sarkarati <Mehran.Sarkarati at esa.int>
Cc: Mario Merri <Mario.Merri at esa.int>, Duhaze Marc <Marc.Duhaze at cnes.fr>, "Reeves, Scott (MSFC-HP27)[HOSC SERVICES CONTRACT]" <scott.reeves at nasa.gov>, Peter van der Plas <Peter.van.der.Plas at esa.int>, CESG <cesg at mailman.ccsds.org>
Subject: Re: [EXTERNAL] Comments on the MAL BB

Dear Mehran, et al,

You and your WG seem to have a very different approach to this process than I do.   Your email makes the statement “Our WG sees this as very unfortunate that you consider the points you have raised as severe enough to stop the Agency review “.  I can easily imagine that being so, but your disappointment is not sufficient reason to let a flawed document go out for agency review as having the backing of CCSDS.  Your email also speaks of “surprised to see new comments on parts that were not changed”, along with your belief that my comments should have been confined only to specific changes and that they were largely editorial and therefore could be easily ignored.  These statements are both wrong and dismissive.

You should all know by now that I do not approach these document reviews lightly.  I, and other members of the CESG, have certain responsibilities as defined in the CCSDS Org & Proc, A02.1-Y-4.  You may not be familiar with the rules that govern CCSDS so I have quoted key sections from the Org & Proc in Blue (emphasis added):

2.3.2.2.g d)  Consistency. An important job of the CESG is to watch over the output of all of the WGs to help prevent CCSDS specifications that are at odds with each other. This is why ADs and DADs are required to review the drafts coming out of Areas other than their own as part of the consensus process leading up to their adoption into the program of work. The quality of the CCSDS Recommended Standards comes both from the review that they get in the WGs and the review that the WG products get from the CESG.

2.3.2.3 CESG Responsibilities

j)  identifying “red flag” items where technical work in a proposed CCSDS document is not of the required quality or nature, where technical work is not progressing satisfactorily, where resources are inadequate, or where significant issues exist, and raising these to the attention of the CMC for corrective action;

6.1.1        In this context, norms are specific and precise rules that elaborate the detailed behavioral and structural requirements of a standard. To say that a section of a standard is “normative” is to say that it is both well specified, i.e., a norm, and that it must be adhered to in order for an implementation to be compliant.

6.1.4.2 The principal difference between these two branches is that Recommended Standards are precise, prescriptive and/or normative specifications that define interfaces, protocols, or other controlling standards at a sufficient level of technical detail that they can be directly implemented and used for space-mission interoperability and cross support. Recommended Standards may be defined at a single layer in the OSI reference model,9 or they may specify how to utilize a set of related standards from several layers in the OSI reference model or how to adapt other standards for use in space.
B1.2 Recommended Standard Branch

d) Pink Books are issued when changes to an existing Blue Book are extensive enough to warrant review of the entire document; Pink Sheets (changed pages only) are issued otherwise. In the case of Pink Sheets, only changes to the current issue of the Blue Book are subject to review.
Here is what I believe is true:

  1.  You made changes to the entire document, not just to “Pink Sheets”, therefore the entire document is under review.  This is our standard practice.
  2.  The MAL has always been “abstract”, this is even stated in its name, and this version makes it even more abstract (and vague).  Your WG seems to think that this is a good thing.  I think that it is the antithesis of what a Blue Book is because it is not “at a sufficient level of technical detail that they can be directly implemented and used for space-mission interoperability and cross support”.
  3.  Because the MAL fails this fundamental test this document is not really a Blue Book.  It is, at best, a Magenta Book that needs to be bound, after the fact, to a specific set of implementation choices to produce something that is in any way interoperable.  This approach says, in essence, “Take this concept, and these two other docs, together, to make a BB MAL sandwich.”  This is unprecedented anywhere else in CCSDS (or in other interoperable standards for that matter).
  4.  Other Areas and WG have separate abstract architecture documents (MB) and properly formalized and implementable Blue Books (BB).  An excellent and parallel example is the CSS abstract “Guidelines for the Specification of Cross Support Transfer Services”, CCSDS 921.2-M-1, and the completely formal and directly implementable standards that are built upon it, such as “Cross Support Transfer Service, Monitored Data Service”, CCSDS 922.1-B-1.  The first provides the architecture and the framework for a variety of different services, the second provides the specific, directly implementable, and interoperable service.  This should sound familiar to you as a concept, but you have missed the mark.
  5.  A last comment is that the only way that any set of interoperable applications can be built using the MAL is to bind them to a specific data representation and a specific transport technology.  This is really the “Blue” part.  You have stated in the past that these different choices (a specific MAL sandwich) can all interoperate using a sort of “generic bridge”, but I have seen evidence in some of these bindings that there is no mapping for some fields. The design of the binding is such that some data must be passed “by management” and therefore outside of the specified interface.   Because of this I have to conclude that anything like full interoperability and idempotence is not generally achievable at the protocol level.

I am aware that there are at least a few agencies who support this whole MAL construct.  I am also aware that there are other agencies who do not believe, after 20 years of development, that is has sufficient value for them to invest in it.  Agencies are entitled to make choices as to what to invest in.  Our job in CCSDS is to try and ensure that when a standard says that it is “at a sufficient level of technical detail that they can be directly implemented and used for space-mission interoperability and cross support” that that is a testable and verifiable truth.

As I have clearly stated, I do not believe that this document has either sufficient detail, nor is it directly implementable, so as to meet this exacting CCSDS Blue Book test.  Instead of taking this re-writing opportunity to improve the MAL and bring it into closer alignment with CCSDS norms you have chosen to make it even more abstract and vague.  I think this is a missed opportunity on your part, but that’s your call.

For some reason you seem to think that all of the feedback provided to the effect that this vagueness is not acceptable is “just editorial”, and therefore can be ignored.  I think you are missing the point and also trying to rewrite the rules that the rest of CCSDS operates by.  But from my point of view if we allow this for the MAL then I fear we shall be pressured to allow such lapses in our level of standards compliance for other documents, and at that point CCSDS will cease to have value to agencies and missions that require interoperability.

So, as a matter of principle, I am going to request that you either fix these lapses in alignment with stated CCSDS Architectural Principles (especially A3, A8, and A10) and document content norms, or that you “re-brand” and rewrite this as the Recommended Practice Magenta Book that it actually is given its current lack of specificity.   The other approach you could take, of course, is to make this document more prescriptive so that it actually meets the criteria for a Blue Book.  This choice is yours.

I do not expect this to make you happy, and I want to assure you that I do not make this request lightly.  I have, in fact, given it a lot of thought and verified, by talking to other CCSDS experts, that I am not mistaken in my analysis nor my judgements.

This is why it took a week to get you a reply.

Best regards, Peter Shames

From: Mehran Sarkarati <Mehran.Sarkarati at esa.int>
Date: Wednesday, June 29, 2022 at 3:17 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Mario Merri <Mario.Merri at esa.int>, Duhaze Marc <Marc.Duhaze at cnes.fr>, "Reeves, Scott (MSFC-HP27)[HOSC SERVICES CONTRACT]" <scott.reeves at nasa.gov>, Peter van der Plas <Peter.van.der.Plas at esa.int>
Subject: [EXTERNAL] Comments on the MAL BB

Dear Peter,

We have reviewed carefully in the WG the comments, which you had raised as part of the CESG review on the updated MAL Book.
Please find attached the responses.
Most of the comments seemed to us editorial and not critical, as they seemed to ask for better wording or clarification, which we accept.
Some comments seemed to be a misunderstanding by you, due to the MS Word track change function (comments made on deleted image and deleted text, etc.).
As you will see in the responses, at least our perception is that there is no big issue and we accept to update the wording and do the editorial updates.

From a procedure perspective, we were expecting comments on the red-lined changed parts of the already published blue book. Since the MAL BB is already a published standard, which has gone through many review cycles, we were a bit surprise to see new comments on unchanged parts of the book. Regardless we have also processed these comments and agreed to most of them.

Our WG sees this as very unfortunate that you consider the points you have raised as severe enough to stop the Agency review and we would like to resolve your points as swift as possible and start the Agency review. Also in order to avoid delays on the agency review of the Mission Planning BB.
We suggest to have a meeting to discuss if there are any major points that we did not understand from your comments and if the provided answers clarify the questions, you have raised.

Please let me know, when would be a good time for you.

Regards
Mehran

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20220707/1f090b2b/attachment-0001.htm>