[Moims-sc] FW: [CESG] [EXTERNAL] MAL PIDs spreadsheet

[Mehran Sarkarati]

Dear SM&C WG,

FYI.

We have the slot on Wednesday at 14:00 to meet with Peter and other ADs.

Regards
Mehran
From: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>
Date: Sunday, 16 October 2022 at 21:55
To: Mehran Sarkarati <Mehran.Sarkarati at esa.int>, Klaus-Juergen Schulz <Klaus-Juergen.Schulz at esa.int>
Cc: Mario Merri <Mario.Merri at esa.int>, "Barkley, Erik J (US 3970)" <erik.j.barkley at jpl.nasa.gov>, "Tomaso.deCola at dlr.de" <Tomaso.deCola at dlr.de>, "Reeves, Scott (MSFC-HP27)[HOSC SERVICES CONTRACT]" <scott.reeves at nasa.gov>
Subject: Re: [CESG] [EXTERNAL] MAL PIDs spreadsheet

Dear Mehran,

As I promised I have now reviewed both the document changes and the Excel spreadsheet.

I found, as you pointed out, that you have removed a number of elements.  In some cases, such as removing the definition of “system” this does not seem to have cause a loss of clarity except in that it was replaced with a reference to “deployment”, which is, by the way, undefined.

That lack of a definition is not a huge issue, but I am pointing it out because the use of terms is important and there are still a number of them, such as that, which are un-evenly handled in this revised document.

There are other issues that I find more troubling.  Many were signaled in your spreadsheet, and having read the document I can confirm that they are a problem.  Among them:


  1.  Removal of references to the transport layer.  You may plan to eliminate the Transport Layer API, and that is your choice.  Such APIs confer portability but not interoperability, so they are more of a programming convenience.  But the whole transport layer part of the architecture is another matter.  Without a clear description of how these abstract message specifications get bound to concrete PDUs, and how those get transported from one set of implemented elements to another you have left out the most significant aspect that does confer interoperability.  Please repair these removed sections (see 2.1, 3.1 and elsewhere).
  2.  There are a number of terms, such as area and domain, which are unevenly handled in the document.  In some cases, such as PubSub, they appear to be named as optional, but then treated as a key field in subscription filtering.  Since the other key field, “optional filters” is also optional, by definition, it is unclear how this can work if these two key fields are both left out.
  3.  The definition of “Object” is, in my estimation, still confusing.  It appears that this really means, specifically “MO data object” and not any of the many other possible kinds of objects.  And it is still treated from the outset not as a specially defined “MO data object”, but just as “object”.  These “MO data objects” are further defined as complex data types with “two characteristics”.  One characteristic is that they have a “unique identity”.  The other seems to be that they can be “referenced unambiguously”.  Unambiguous references seem to be defined in 4.3.1, “Object”, and there is a pointer to 4.4.19 intended to disambiguate MAL ObjectRef type, which itself points to 4.1.7.1.  But 4.1.7.1 is all about polymorphism, I do not think that has anything to do with “unambiguous references”.  Maybe I am old fashioned, but none of this seems to really define “unambiguous reference” in any truly concrete way.  Object identity, nailed down in sec 4.3.2, seems to be much more concretely defined, but this also references “Area” which is optional, hence leading to some further apparent ambiguity.

I can go on about these detailed matters, but there is still the big one to deal with, so let’s get to it.

Just how does this abstract spec relate to true interoperability in the way that the rest of CCSDS defines it?

In the process of reviewing this revised spec I noticed two things:

  *   There is now text in sec 3.4.1.4 that explicitly makes a statement that the type of the fields in “From” and “To” addresses are arbitrary, may have different bindings, and must be set in an ICD.  Note that these “Form” and To” fields are in every PDU, but that defining and disambiguating them is to be done in an ICD.
  *   There is text in sec 2.3, abstract services, that also makes the very clear point that Services can use names, or numbers, or something else as identifiers and that these choices are transport specific.  It does not mention use of an ICD, but that is the obvious place to document these things as well.

As I keep pointing out, the entirety of this specification is abstract and therefore not directly implementable.  It is impossible to read this spec and imagine it being turned into something that can successfully interoperate without the aid of an extensive ICD to document all of these field types (not just values), which are included, which are used, how these “unambiguous names” are defined, which fields are included or optional.  This has to be true for concrete data types, for concrete mapping to data representations, for service addresses, for the fields used in the services themselves, and for the transport bindings.

Note that this is entirely different from the way that all other interoperable services in CCSDS (and elsewhere) are specified.  Data exchanges, such as Nav, need no such ICD.  Protocol specs, as in the entirely of SLS and SIS need no such ICDs, but small ICDs are used for specific uses of data field values, not for the fields themselves nor the PDUs.  Service specs like SLE and CSTS need no such complicated ICDs.  They do employ simple ICDs for IP address and ports, but these are field vales, not field definitions, and there are only a few such values.  Everything else for SLE and CSTS is directly in the published specs.

Only the MO MAL has these added layers of data abstractions, data type variations, data and transport bindings, which fields are used, how they are defined, and the need for extensive ICDs to document all of this stuff which can clearly differ from one implementation and deployment to the next.  These variations are at the protocol data unit level, the data type level, and the data format and transport binding level.

As I have said before, I remain firmly convinced that there is no way that this specification meets the CCSDS Blue Book definitions of being “complete, unambiguous, amd directly implementable for interoperability and cross support”.

Sec B.1.1 Blue Book

CCSDS Recommended Standards (Blue Books) define specific interfaces, technical capabilities, or protocols, or provide prescriptive and/or normative definitions of interfaces, protocols, or other controlling standards such as encoding approaches. Recommended Standards must be complete, unambiguous and at a sufficient level of technical detail that they can be directly implemented and used for space-mission interoperability and cross support.
There seems to be a strong desire to have this remain published as a Blue Book, but I think that does a real disservice to all the rest of the CCSDS Blue Books, and for all of the technical reasons just stated.  I think this must be addressed at CESG level.

I’ll see you at the meeting where we can try to address the technical issues within the document, regardless of which color it gets published as.

Best regards, Peter


From: Mehran Sarkarati <Mehran.Sarkarati at esa.int>
Date: Tuesday, October 11, 2022 at 12:52 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>, Klaus-Juergen Schulz <Klaus-Juergen.Schulz at esa.int>
Cc: Mario Merri <Mario.Merri at esa.int>, Erik Barkley <erik.j.barkley at jpl.nasa.gov>, "Tomaso.deCola at dlr.de" <Tomaso.deCola at dlr.de>, "Reeves, Scott (MSFC-HP27)[HOSC SERVICES CONTRACT]" <scott.reeves at nasa.gov>
Subject: Re: [CESG] [EXTERNAL] MAL PIDs spreadsheet

Dear Peter,

Thank you for providing answers. I believe you have go a wrong impression by only reading the answers and not looking to the document.
I invite you to read the document and complete your review.


I do not wish to have a long email exchange. I limit myself to one single example of PID #2.
You had originally raised a comment on the definition of the term SYSTEM.
EB has reviewed and provided the comment “The term "Service System" is defined (section 1.4) but not subsequently used in the document.  The term "system" is used in section 2.1 ("...Moving from the abstract to the implemented system, two other specifications are needed….").  This appears to be the only use of the word "system" that is not included as part of CCSDS defintion or standard CCSDS boilerplate, or other commonly understood usage such as in "operating system".  As such believe the defintion can be removed from section 1.4.”

We have checked the document and the word System or Service System does not appear anywhere and hence have removed the definition in section 1.4.
Now you have provided again another comment to referencing a different definition of the term.
We are ok with adding any reference to resolve the PID but this is an example of how we are going in cycles with your PIDs.

Same is through for PID3 we have removed the definitions for Protocol, Protocol stack, Protocol Access point as they were and are not used ANYWHERE in the document.
We have added clear references to the other standards as you had suggested: XML, URI, IEEE STD 754-2019 and UniCode
Now again you have provided a long conceptual/high level comment.
If your point is to add a reference to ISO 7498, we are ok and can simply add this reference (even if we do not understand why!) to close the PID. If not, then I do not see how we shall satisfy you.

Another example is PID5 we have rewritten the section that explains the Object. We have reworded all the appearances of the Object, updated the definition and made the whole book to be consistent and clear. We removed the ambiguity and also unnecessary sentences that refer to the Object. Without reading the document, you seem to have got the impression that we are hiding information. The contrary is true. We have been more explicit and very clear about the point of the PID by updating various parts of the document.

I stop here, because otherwise I would need to add clarification for each of the PIDs!

I’d like to call for a 2 hours meeting during the Fall Technical meetings. Please let us know your availability on Tuesday, Wednesday or Friday.
We have 28 PIDs.  You have provided “OK” for 5 PIDs. This leaves 23 PIDs.
In the meeting, we shall go one by one through the PIDs. In order to allow all the PIDs to be reviewed, I suggest to allocate 5 minutes per PID and implement a strict time keeping.
If we exceed the time per each PID without being able to agree, we shall mark it as to be reported to CESG.
I would very much appreciate if you can be very clear of what exactly you want to see for each PID to flag it as “OK”.

After the meeting, we shall send to KJS the list of the PIDs that could not be agreed (hopefully none).
As agreed during the meeting with CESG, KJS would call for one more meeting at CESG level to review these PIDs and if they can not be closed in that meeting, escalate the matter to CMC.

Regards
Mehran



From: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>
Date: Monday, 10 October 2022 at 19:59
To: Mehran Sarkarati <Mehran.Sarkarati at esa.int>, Klaus-Juergen Schulz <Klaus-Juergen.Schulz at esa.int>
Cc: Mario Merri <Mario.Merri at esa.int>, "Barkley, Erik J (US 3970)" <erik.j.barkley at jpl.nasa.gov>, "Tomaso.deCola at dlr.de" <Tomaso.deCola at dlr.de>
Subject: Re: [CESG] [EXTERNAL] MAL PIDs spreadsheet

Dear Mehran & team,

In order to provide you with what I hope is some useful early feedback I have reviewed your PID responses and offered my comments.  I want to be clear that I have not yet had the time to read the document as edited, these are responses to your responses in spreadsheet form.  As always it is possible that we are “talking past one another” and misunderstanding the point that each of us is trying to make.

My major impression of the responses is that instead of clarifying issues pointed out in many of these PIDs, from me, Erik, and Tomaso, that you chose to remove sections of the document.  You will see these concerns expressed in my responses to PID #2, 3, 4, 5, 15 and elsewhere.  This is a complicated framework with a lot of moving parts.  It is your responsibility to accurately and completely document it so that the readers understand what it is and what it does.  Hiding parts, or failing to key address parts, is not a viable approach, and this is true for mandatory as well as defined optional elements.

I used the word “transparency” in some of my responses in a way that may not be familiar to you.  This is what I meant:

Literarily, being transparent means being easily seen through. The context of transparency in an organization's actions and the team's communication is as simple as it is: No secrets. It is taking actions in such a way that others can easily see them.

Or, in my words, describing the inherent complexity such that it can be understood and not hiding it.

You will see that I added a PID# column.  I wanted to make the cross references to PIDs obvious, some appeared to be incorrect.

Your response to security feedback seems to fall into that “defer or remove” category.  In this day and age I think that is a mistake.  We should be moving toward a ZTA approach and not away from it, especially where user data from multiple sources is involved.  Surely that is the domain in which MAL is intended to be deployed.

Your responses to several PIDs relating to interoperability also read like you are backing away from the responsibility for providing a set of standards that support that capability.  I am thinking particularly of PID #15, 16, 22, and 23.  Perhaps this is a difference in the way that you are using language, but the ability of these specs to support interoperability remains a major concern.  See especially the Internet example offered in my response to PID #15.

You will also see that there are quite a number of places where my notes say “Review”, or “Review document for clarity”.  I have not yet done that, but I will and will provide you with an update of this file.  In the meantime I think that this will give you something useful to chew upon.

Regards, Peter



From: Mehran Sarkarati <Mehran.Sarkarati at esa.int>
Date: Wednesday, October 5, 2022 at 5:33 AM
To: Klaus-Juergen Schulz <Klaus-Juergen.Schulz at esa.int>, Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Mario Merri <Mario.Merri at esa.int>
Subject: Re: [CESG] [EXTERNAL] MAL PIDs spreadsheet

Dear Peter and Klaus Jürgen,

@Klaus-Jürgen Since I do not have the email of Tomaso and Erik, could you please forward them this note.

@Peter, Erik, Tomaso: Please find attached the updated Excel sheet with the updated PID disposition answers and the updated BB. The SM&C WG has reviewed your comments carefully and have put an effort to update the book accordingly.

I’d appreciate if you could have a look and let me know if you are satisfied with the answer and the update. In case there are any PIDs that you believe need more discussion or you are not happy with our answer/update, please indicate them. I will then organize a meeting to go one by one through those PIDs.

Regards
Mehran



From: Klaus-Juergen Schulz <Klaus-Juergen.Schulz at esa.int>
Date: Friday, 29 July 2022 at 16:53
To: Mehran Sarkarati <Mehran.Sarkarati at esa.int>
Subject: FW: [CESG] [EXTERNAL] MAL PIDs spreadsheet



From: CESG <cesg-bounces at mailman.ccsds.org> On Behalf Of Tomaso de Cola - SIS AD via CESG
Sent: 29 July 2022 16:49
To: cesg at mailman.ccsds.org
Subject: Re: [CESG] [EXTERNAL] MAL PIDs spreadsheet

Dear All,

Following Erik’s email, I also looked into the excel sheet prepared by Peter with all remarks&iterations made by him, Mehran, and further extended by Erik. I’ve also added a few comments (updated version herewith attached, also uploaded on cwe).

In general, as already commented during the telco a few weeks ago, I don’t see unrecoverable points. In particular:


  1.  This is a revision of an existing blue book and I think it’s not appropriate to move it to a different track (i.e. magenta), since this revision is indeed part of the current WG charter.
  2.  The main critical points are in my opinion confined to the first sections in terms of definition, terminology and overall scope. Then, the security implications are also currently vaguely addressed, whereby a rework of this will be probably necessary.
  3.  Some of the points have been in part already answered by Mehran (and in general by the WG), so that probably implementing the remaining points should not be an exhausting exercise.
  4.  Last but not the least, I know that the preparation of the book has been subject to thorough iterations in the WG in order to take into account all concerns/requirements exposed by the different agencies. Moreover I have the impression the delayed agency review is affecting also books under preparation in the same WG or at least within the overall MOIMS area. I certainly concur that a book can go to agency review only when fulfils certain CESG quality principles, but we cannot certainly delay the process forever, more importantly if the book is a (in my opinion light) revision of an existing one. Maybe some points could have been even directly raised during agency review.

Best Regards,

Tomaso


From: CESG <cesg-bounces at mailman.ccsds.org<mailto:cesg-bounces at mailman.ccsds.org>> On Behalf Of Barkley, Erik J (US 3970) via CESG
Sent: Donnerstag, 28. Juli 2022 02:31
To: cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>
Subject: Re: [CESG] [EXTERNAL] MAL PIDs spreadsheet

Dear CESG Colleagues,

At the July 18 meeting I agreed to take a look at the spreadsheet that Peter prepared and to check the PIDs listed therein against the latest MAL document. Essentially to perform a review of the review. Accordingly, please see the attached spreadsheet.

My conclusion is that, on balance, there does indeed need to be some revision of the document prior to agency review. Having said that, I will note, that as I was on vacation and did not participate in the vote, these are of course not any kind of conditions but rather hopefully some assistance in sorting out the PIDs that were recorded for the vote.  To be more specific, my findings can be summarized as:


  1.  Terminology is used in multiple senses in different parts of the document and/or not defined in the terminology section; this tends to lead some definitions that are circular (e.g., “…attribute extends ‘Attribute’…”)
  2.  The PICs proforma is not properly stated (see comments in the spreadsheet)
  3.  It seems that some sort of requirements on the transport layer should be stated
  4.  Cybersecurity needs to be addressed

I will also note there are some of the PIDs where I think Peter stated some things incorrectly and/or I did not really see the issue.  Perhaps this is a case where the definition of success is getting everybody angry at you :-)

Best regards,
-Erik

Ps, the spreadsheet has also been uploaded to the CWE space used for the July 18 meeting.

From: CESG <cesg-bounces at mailman.ccsds.org<mailto:cesg-bounces at mailman.ccsds.org>> On Behalf Of Barkley, Erik J (US 3970) via CESG
Sent: Monday, July 18, 2022 12:25
To: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Cc: cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>
Subject: [EXTERNAL] [CESG] MAL PIDs spreadsheet

Hello Peter,

As you may recall, I volunteered to take a look at the MO MAL Agency Review CESG Poll PIDs and check them against the latest MAL document.  I see the presentation, dated July 11 in the CWE for CESG, but I do not find the spreadsheet there.  Can you please either send or (probably better) post the spreadsheet?  Thank you.

Best regards,

Erik Barkley
Cross Support Services Area Director
Consultative Committee for Space Data Systems
www.ccsds.org<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Feur05.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Feur05.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__http*3A*2Fwww.ccsds.org*2F__*3B!!PvBDto6Hs4WbVuu7!Y0McA6Xa7qWSD4GzCyzGhggymTsKhLx6dMHJiWUY4A3Ly3w10ibGmgeOXvMf5Lrq9nyAxLFrYw*24*26data*3D05*7C01*7CMehran.Sarkarati*40esa.int*7Ca0c5369ae0a54b70206408da71721730*7C9a5cacd02bef4dd7ac5c7ebe1f54f495*7C0*7C0*7C637947032304877953*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C*26sdata*3DiRi80tUDYcwg*2BrbLBbqXPAMIKYeKZE1k*2Fp9p7MoNyr4*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!YMbDz5wWMMOukmAvpzmRtTRe7o5dfwncKdJxRJ4JJuu2p9gL-lL4qqoJfi7mDeyJun42zc4D*24%26data%3D05*7C01*7CMehran.Sarkarati*40esa.int*7C3fc19a7c2c7a4daf49fb08daaae91b75*7C9a5cacd02bef4dd7ac5c7ebe1f54f495*7C0*7C0*7C638010215416743266*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C%26sdata%3Df22LCH*2FNvjcuA3xjjebO*2FYwVYi7WGSSVQioZ6cbFz6k*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSoqKioqKioqKiolJSoqKioqKioqKioqKioqKiUlKioqJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!cJLR-FTVYHhDopgFQewTADe1ZaZgFwJgJJg44JHSG_vbq9lnLIdpEQLyRlhuPPH0LzzBpzbg%24&data=05%7C01%7CMehran.Sarkarati%40esa.int%7C9185cb97ce324c26b42908daafb04ebd%7C9a5cacd02bef4dd7ac5c7ebe1f54f495%7C0%7C0%7C638015469029523358%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4nq76vb9RiQbq7VaPlaKssuolsu4F0XAMPOqPQNfonQ%3D&reserved=0>

+1 818.393.4972

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).
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/20221017/9e079b4e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MAL_Book_521.0-B-3_v0.93-SEA.doc
Type: application/msword
Size: 2424320 bytes
Desc: MAL_Book_521.0-B-3_v0.93-SEA.doc
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20221017/9e079b4e/attachment-0001.doc>