[Moims-sc] [EXTERNAL] [MOv2] Removing a MAL object: precision needed

Wed May 31 05:53:26 UTC 2023

I may not be understanding all of the implications of this, but this appears to be an issue of CM and version control.

If these objects are effectively global in nature then I believe that this CM and version control needs to be done globally.  If it is “localized” in some way, relative to a system, then I believe that the CM needs to be handled local to that deployment.

To not handle CM and versioning, and to allow any system element to delete, redefine, etc elements without control or marking that this had occurred seems to me like a recipe for disaster.

Note that I am assuming that this redefinition implies changing type, number, or order of formal parameters.  It does not imply that the values of these parameters cannot be changed.

Regards, Peter

From: MOIMS-SC <moims-sc-bounces at mailman.ccsds.org> on behalf of MOIMS-SC MOIMS-SC <moims-sc at mailman.ccsds.org>
Reply-To: Churlaud Olivier <Olivier.Churlaud at cnes.fr>
Date: Tuesday, May 30, 2023 at 6:20 AM
To: MOIMS-SC MOIMS-SC <moims-sc at mailman.ccsds.org>
Subject: [EXTERNAL] [Moims-sc] [MOv2] Removing a MAL object: precision needed

Dear all,

I just finished a telecon with Serge about some expected behaviors in the Aggregation service, and it appears that we have a hole somewhere that would need precision.

We often define operations in services that add and remove MAL objects.
What happens if I remove a MAL object and add another one with the same KEY ?
I see 3 possibilities:

  1.  It’s not authorized : the key is lost forever and thus…..the provider needs a database with all existing keys of the world
  2.  It’s authorized but the version must be bumped so that a consumer knows that something happened with it. The provider needs a database with all existing keys and their current version. It means also that add/remove operations are rather upgrade/disable.
  3.  It’s authorized and the key is initialized to 1. The risk is that the consumer loses its mind, specifically in multi-users scenarios, but everythink is way simpler

I would vote for (c) that is simplier in all ways and would only need to add a sentence in the bluebook.
In this case, it means that this scenario is possible:

  1.  ESA creates aggregation GreatAggreg = [param1, param2, param10]
  2.  Someone (ESA, CNES or another teamplayer) deletes the aggregation GreatAggreg
  3.  CNES creates the aggregation GreatAggreg = [param12,param3]
  4.  ESA receives an aggregation GreatAggreg and is not able to understand it.

  *   ESA’s software (and every multi-player software) has to be robust to this case or have implementation specific code to forbid it.

Do you have opinions about this?

Best regards
Olivier

[cid:image001.png at 01D99349.8A9470E0]
Olivier CHURLAUD
Architecte Segment Sol d'Opération
Sous-Direction Opérations,
Service Développement de Segments Sol d’Opérations
18 avenue Edouard Belin 31401 Toulouse Cedex 9
[cid:image002.png at 01D99349.8A9470E0] +33 (0)5 61 28 19 08
[cid:image003.png at 01D99349.8A9470E0] olivier.churlaud at cnes.fr
[cid:image004.png at 01D99349.8A9470E0] cnes.fr<https://urldefense.us/v3/__http:/cnes.fr/__;!!PvBDto6Hs4WbVuu7!LAw25WhRGxwWYYEiz6aQ9QrQf6Pdz_GDvKgqqYT9du_ls0-dy6gmrsoazS4vcmRyNRaAXnOy0NXye0fychAnU9pw6hRWwiFe$>
[cid:image005.png at 01D99349.8A9470E0]<https://urldefense.us/v3/__https:/www.facebook.com/CNESFrance/__;!!PvBDto6Hs4WbVuu7!LAw25WhRGxwWYYEiz6aQ9QrQf6Pdz_GDvKgqqYT9du_ls0-dy6gmrsoazS4vcmRyNRaAXnOy0NXye0fychAnU9pw6nPEcfo4$>  [cid:image006.png at 01D99349.8A9470E0] <https://urldefense.us/v3/__https:/www.instagram.com/cnes_france/__;!!PvBDto6Hs4WbVuu7!LAw25WhRGxwWYYEiz6aQ9QrQf6Pdz_GDvKgqqYT9du_ls0-dy6gmrsoazS4vcmRyNRaAXnOy0NXye0fychAnU9pw6jrEwB-f$>   [cid:image007.png at 01D99349.8A9470E0] <https://urldefense.us/v3/__https:/twitter.com/cnes__;!!PvBDto6Hs4WbVuu7!LAw25WhRGxwWYYEiz6aQ9QrQf6Pdz_GDvKgqqYT9du_ls0-dy6gmrsoazS4vcmRyNRaAXnOy0NXye0fychAnU9pw6qtcVbbU$>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20230531/dd6dc66f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 8694 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20230531/dd6dc66f/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 481 bytes
Desc: image002.png
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20230531/dd6dc66f/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 529 bytes
Desc: image003.png
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20230531/dd6dc66f/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 527 bytes
Desc: image004.png
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20230531/dd6dc66f/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 808 bytes
Desc: image005.png
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20230531/dd6dc66f/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 877 bytes
Desc: image006.png
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20230531/dd6dc66f/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 859 bytes
Desc: image007.png
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20230531/dd6dc66f/attachment-0013.png>