[Ccsds-omg-liaison] Second AB Review: Ground Data Delivery Interface (GDDI) RFP

Thu Dec 8 16:19:57 UTC 2022

Thanks Justin,

I uploaded the document, it's on the AB and DTC agendas

Best regards,

-Juergen

Jürgen Boldt
Boston, MA, USA UTC-05
From: J Boss <wkbrd.stds at gmail.com>
Sent: Thursday, December 8, 2022 9:46 AM
To: Manfred Koethe <koethe at 88solutions.com>
Cc: Justin.Boss at kratosdefense.com; space at omg.org; ab at omg.org
Subject: Re: Second AB Review: Ground Data Delivery Interface (GDDI) RFP

Hi all,

We have made many updates to the GDDI specification and would appreciate the review of the AB.

Please find the updated version attached.

Juergen, please upload this as 2022-12-07.  (Other documents reviewed this week will be logged with earlier document numbers).

-Justin

On Sun, Dec 4, 2022 at 6:06 PM Manfred Koethe <koethe at 88solutions.com<mailto:koethe at 88solutions.com>> wrote:
Hi Justin,

This is my review of the revised RFP, document number space-2022-12-01.
The RFP improved to some extent, but is still in its formal appearance, presentation
of the desired technical goals, and descriptive precision of the requirements far
from releasable as an OMG RFP.

It is very hard to understand what you *really* are soliciting. And until this is not
made absolutely clear, the RFP is not releasable.

The best description is in the first bullet of the Objective section. Here you say:

"A platform-independent interface model for the transfer of spacecraft data and
metadata between ground applications within an Internet Protocol (IP) network."

While this is *very* broad, it at least communicates a sense about what you are
looking for. But it has also that "Internet Protocol (IP) network" phrase in it, which
is misplaced for an OMG standard. As I wrote in my initial review, the OMG is
*not* in the business to specify network or wire protocols, and with that I mean
data link and transport level protocols. What you are looking for, IMHO, is an
application-level or session-level protocol. If your Figure 1 and your situational
description in 6.1 is accurate, then you really want to deal only with the protocol
securing and managing your space data transmissions, and *hide* the underlying
network stuff as much as you can. Again, if your Figure 1 is accurate, then you
have to deal with many different applications, running on potentially many different
operating systems, with potentially slightly different network stack implementations,
even within a system class, like "Linux". In these days, TCP/IP networks are
predominant, but still can expect a pure ISO-OSI network somewhere in your path, in
particular in Europe, and those networks are (slightly) different. But even within
the TCP/IP family you have IP4 and IP6 based stacks, which differ quite some
on lower levels. A good network stack implementation hides all these nitty-gritty
differences, so I recommend to stay out of the underlying mess and think about an
application, or at most, session level protocol. It is a wrong myth that you get better
throughput if you bypass the network stack and "fiddle" on a very low level.

To make the long story short, you want to harmonize a wildly-grown "zoo" of
"space data applications" (allow me this general designator). To be successful
with this, you need to think about an extensible metamodel describing your
data. It must be really extensible without side effects on the definitions given
by earlier iterations of that metamodel, only this way your environment can
digest the unavoidable growth. Please look to the (fairly old) Common
Data Warehouse Metamodel (CWM, https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.omg.org%2Fspec%2FCWM&data=05%7C01%7Cspace%40omg.org%7C543d06f87ab842247acb08dad9380edd%7C43ba4fbcdc0a4269b50364f0363799d8%7C0%7C0%7C638061132051697257%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9YX306SYhotvbdo6w6PIipf5zN2FH1GetNVqLQyW0XE%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.omg.org%2Fspec%2FCWM&data=05%7C01%7Cspace%40omg.org%7C543d06f87ab842247acb08dad9380edd%7C43ba4fbcdc0a4269b50364f0363799d8%7C0%7C0%7C638061132051697257%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9YX306SYhotvbdo6w6PIipf5zN2FH1GetNVqLQyW0XE%3D&reserved=0>) for
inspirations. CWM solves exactly the same problem as yours for the database
domain.

So the metamodel must be the #1 item, but for that you need a clear idea what
data need to be transferred, and how these data are structured. That should
guide your PIM requirements.

Then, all the involved applications need to work with the data described by
the metamodel. For that you need to specify interfaces. This is #2 priority for
your RFP and results in the PSM requirements.

Now you need to think about the technologies submitters shall use.
For the PIM, UML or MOF are good candidates, for the PSM, IDL would
(IMHO) be the best candidate. With IDL you get consistently declared
interfaces, while the vast number of available language bindings can satisfy
even exotic applications.

Then, and only then, you can think about transmission. But *DO NOT* drop
down into the network stack! Instead think about transmission requirements,
and from those specify requirements for a Quality of Service (QoS) protocol.
QoS gives you a handle on transmission requirements without the need to
fiddle with network stuff directly. Therefore, forget about things like explicit
throughput figures like in your requirement #11, find an equivalent QoS
parameter, like "at minimum 2 data package units per second", or so.

So, now, after that very long intro, some more concrete things:

Section 6.1 and 6.2 need a major re-write. Nobody will understand *what*
data you exactly want to transfer. Give concrete examples.

Section 3 is a mess. You need to provide clear references to the technologies
to be used to create responses. For example, since you want the submitters
to use UML, you write:

[UML]   Unified Modeling Language, version 2.5.1
             https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.omg.org%2Fspec%2FUML%2F2.5.1%2F&data=05%7C01%7Cspace%40omg.org%7C543d06f87ab842247acb08dad9380edd%7C43ba4fbcdc0a4269b50364f0363799d8%7C0%7C0%7C638061132051697257%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=82NWICVaJ47xoeHA9hDgZxrWkbyb3XGcym2i704vWf0%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.omg.org%2Fspec%2FUML%2F2.5.1%2F&data=05%7C01%7Cspace%40omg.org%7C543d06f87ab842247acb08dad9380edd%7C43ba4fbcdc0a4269b50364f0363799d8%7C0%7C0%7C638061132051697257%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=82NWICVaJ47xoeHA9hDgZxrWkbyb3XGcym2i704vWf0%3D&reserved=0>

 or for MOF, you write:

[MOF]    Meta Object Facility, version 2.5.1
              https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.omg.org%2Fspec%2FMOF%2F2%2F5.1%2F&data=05%7C01%7Cspace%40omg.org%7C543d06f87ab842247acb08dad9380edd%7C43ba4fbcdc0a4269b50364f0363799d8%7C0%7C0%7C638061132051697257%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mLEBBhr%2BuYG6a31hDoFODY4JQwqzcWmdNPR2Pe7h5j8%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.omg.org%2Fspec%2FMOF%2F2%2F5.1%2F&data=05%7C01%7Cspace%40omg.org%7C543d06f87ab842247acb08dad9380edd%7C43ba4fbcdc0a4269b50364f0363799d8%7C0%7C0%7C638061132051697257%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mLEBBhr%2BuYG6a31hDoFODY4JQwqzcWmdNPR2Pe7h5j8%3D&reserved=0>

 or for IDL, you write:

 [IDL]     Interface Definition Language, version 4.2
              https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.omg.org%2Fspec%2FIDL%2F4.2%2F&data=05%7C01%7Cspace%40omg.org%7C543d06f87ab842247acb08dad9380edd%7C43ba4fbcdc0a4269b50364f0363799d8%7C0%7C0%7C638061132051697257%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FB6jSeyzmcIn%2BbjSXzmzyTa4RTH4N0buFFEluOyEA9M%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.omg.org%2Fspec%2FIDL%2F4.2%2F&data=05%7C01%7Cspace%40omg.org%7C543d06f87ab842247acb08dad9380edd%7C43ba4fbcdc0a4269b50364f0363799d8%7C0%7C0%7C638061132051697257%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FB6jSeyzmcIn%2BbjSXzmzyTa4RTH4N0buFFEluOyEA9M%3D&reserved=0>

 Every of these references should be followed by a short paragraph arguing why
 submitters shall use this  technology.

 I think this gives you the pattern. Extend this also for OMG-work-in-progress things
 you want to mention, but for these you cannot *mandate* the use, you need to write
 "Submitters are encouraged to {use | refer to} that-and-that technology", or something
 along that line.

 Then your requirements...

 They need to be concise and precise. Each requirement must ask for just ONE thing.
 No big prosa expalantions within requirements, if there is need for explanations, that
 must go into 6.2 and the requirement just referencing it.

 Also, every requirement must have a unique identifier, not just a simple list number.
 Some RFPs use a simple "6.5.n" scheme, some use real identifiers like for example
 "MPIM01" for the first mandatory requirement ablut the PIM. Submitters must then
 refer to these requirements identification in section 0 of the submission and explain
 how the requirement was satisfied.

 Non-Mandatory Requirements are then either "6.6.m" or for example NMFeature03"
 for Non-Mandatory Feature 3.

 I think you got the pattern again.

 Then, Issues to be discussed:

Don't ask for explaining how requirements are fulfilled.

You must make the submitters explain complicated things, like how their solution
is guaranteeing minimum QoS behavior, and so on.

About your IPR mode.

I mean it is your discretion, but I really don't understand what your motivation is
to specify the fairly restrictive "RF Limited" IPR mode. It is my feeling that you
should a wide mix of proprietary and open-source solutions as responses. That
means that the "Non Assert Covenant" IPR mode would be much appropriate.

I hope you are not just want to write this RFP so that you can submit just your
own solution, then protected by "RF Limited". That is not what the OMG stands
for, and what the purpose of standardization is.

I encourage you to consider "Non Assert Covenant". All new OMG specification
tend to use this, and "RF L:imited" is only used if old, pre-IPR Policy license
obligations from an older version of the technology exist.

Finally, your time table is too tight. You need to relax it quite substantially. But almost
every RFP has that problem initially. Remember, nobody within the OMG has been
punshed for delivering eralier....

Ok, this has been a lot. And this RFP needs a lot of more work. I suggest to
work on it and plan for the Spring OMG meeting. Let me know if you need some
help.

Kind regards,

Manfred
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/ccsds-omg-liaison/attachments/20221208/e34a22da/attachment-0001.htm>