<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Thanks Justin,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I uploaded the document, it’s on the AB and DTC agendas<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Juergen<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="FONT-SIZE: 10pt; FONT-FAMILY: ARIAL">Jürgen Boldt<br><span style="font-size: 10pt;">Boston, MA, USA UTC-05<br></span></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> J Boss <wkbrd.stds@gmail.com> <br>
<b>Sent:</b> Thursday, December 8, 2022 9:46 AM<br>
<b>To:</b> Manfred Koethe <koethe@88solutions.com><br>
<b>Cc:</b> Justin.Boss@kratosdefense.com; space@omg.org; ab@omg.org<br>
<b>Subject:</b> Re: Second AB Review: Ground Data Delivery Interface (GDDI) RFP<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Hi all,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We have made many updates to the GDDI specification and would appreciate the review of the AB.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Please find the updated version attached.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Juergen, please upload this as 2022-12-07. (Other documents reviewed this week will be logged with earlier document numbers).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-Justin<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Sun, Dec 4, 2022 at 6:06 PM Manfred Koethe <<a href="mailto:koethe@88solutions.com">koethe@88solutions.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi Justin,<br>
<br>
This is my review of the revised RFP, document number space-2022-12-01.<br>
The RFP improved to some extent, but is still in its formal appearance, presentation<br>
of the desired technical goals, and descriptive precision of the requirements far
<br>
from releasable as an OMG RFP.<br>
<br>
It is very hard to understand what you *really* are soliciting. And until this is not
<br>
made absolutely clear, the RFP is not releasable.<br>
<br>
The best description is in the first bullet of the Objective section. Here you say:<br>
<br>
"A platform-independent interface model for the transfer of spacecraft data and<br>
metadata between ground applications within an Internet Protocol (IP) network."<br>
<br>
While this is *very* broad, it at least communicates a sense about what you are <br>
looking for. But it has also that "Internet Protocol (IP) network" phrase in it, which<br>
is misplaced for an OMG standard. As I wrote in my initial review, the OMG is <br>
*not* in the business to specify network or wire protocols, and with that I mean<br>
data link and transport level protocols. What you are looking for, IMHO, is an<br>
application-level or session-level protocol. If your Figure 1 and your situational<br>
description in 6.1 is accurate, then you really want to deal only with the protocol<br>
securing and managing your space data transmissions, and *hide* the underlying<br>
network stuff as much as you can. Again, if your Figure 1 is accurate, then you<br>
have to deal with many different applications, running on potentially many different<br>
operating systems, with potentially slightly different network stack implementations,<br>
even within a system class, like "Linux". In these days, TCP/IP networks are<br>
predominant, but still can expect a pure ISO-OSI network somewhere in your path, in<br>
particular in Europe, and those networks are (slightly) different. But even within<br>
the TCP/IP family you have IP4 and IP6 based stacks, which differ quite some<br>
on lower levels. A good network stack implementation hides all these nitty-gritty<br>
differences, so I recommend to stay out of the underlying mess and think about an<br>
application, or at most, session level protocol. It is a wrong myth that you get better<br>
throughput if you bypass the network stack and "fiddle" on a very low level.<br>
<br>
To make the long story short, you want to harmonize a wildly-grown "zoo" of<br>
"space data applications" (allow me this general designator). To be successful<br>
with this, you need to think about an extensible metamodel describing your<br>
data. It must be really extensible without side effects on the definitions given<br>
by earlier iterations of that metamodel, only this way your environment can<br>
digest the unavoidable growth. Please look to the (fairly old) Common<br>
Data Warehouse Metamodel (CWM, <a href="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" originalSrc="https://www.omg.org/spec/CWM" shash="QLnTrrP00SvqnNXlri9t8nPWMiJ47YS+R64elyY0K0KtlylgZWPKI6QZayLc4/x1SX4JC9QLLVRWK15LEJsjeztbLtEvgc/3mv7wkdDS9HVMXF7RP98a1wjqp+DXK0uVSF+6V6MafyiE8nHGJszjIEGvMYLCTIYojpqMnv8goXU=" originalsrc="https://www.omg.org/spec/CWM" shash="di7T6mxgt0I3TbnOBi2irLz4vBHfrq2+mLGx0unCZmsvljGo9i8+ePXC5LaexueI5DObvuJy7nT8N8JhMRg1kVbMAJPvLvXu+Xm5C/YNLtS+mNKqOodIMuaTqatXht7G92misWUSIEm3RT8asOKJ8KvJpH9CL16IbOiNcXLvSGs=" target="_blank">
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.omg.org%2Fspec%2FCWM&data=05%7C01%7Cspace%40omg.org%7Cbae78bda278e416d078a08dad64bd52a%7C43ba4fbcdc0a4269b50364f0363799d8%7C0%7C0%7C638057918448865431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tglH5eYgoHaLaGrA6RHpWgJQjkB79vdfYEWam8vvINM%3D&reserved=0</a>)
for<br>
inspirations. CWM solves exactly the same problem as yours for the database<br>
domain.<br>
<br>
So the metamodel must be the #1 item, but for that you need a clear idea what<br>
data need to be transferred, and how these data are structured. That should<br>
guide your PIM requirements.<br>
<br>
Then, all the involved applications need to work with the data described by<br>
the metamodel. For that you need to specify interfaces. This is #2 priority for<br>
your RFP and results in the PSM requirements.<br>
<br>
Now you need to think about the technologies submitters shall use.<br>
For the PIM, UML or MOF are good candidates, for the PSM, IDL would <br>
(IMHO) be the best candidate. With IDL you get consistently declared<br>
interfaces, while the vast number of available language bindings can satisfy<br>
even exotic applications.<br>
<br>
Then, and only then, you can think about transmission. But *DO NOT* drop<br>
down into the network stack! Instead think about transmission requirements, <br>
and from those specify requirements for a Quality of Service (QoS) protocol.<br>
QoS gives you a handle on transmission requirements without the need to<br>
fiddle with network stuff directly. Therefore, forget about things like explicit<br>
throughput figures like in your requirement #11, find an equivalent QoS<br>
parameter, like "at minimum 2 data package units per second", or so.<br>
<br>
So, now, after that very long intro, some more concrete things:<br>
<br>
Section 6.1 and 6.2 need a major re-write. Nobody will understand *what*<br>
data you exactly want to transfer. Give concrete examples.<br>
<br>
Section 3 is a mess. You need to provide clear references to the technologies<br>
to be used to create responses. For example, since you want the submitters<br>
to use UML, you write:<br>
<br>
[UML] Unified Modeling Language, version 2.5.1<br>
<a href="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" originalSrc="https://www.omg.org/spec/UML/2.5.1/" shash="n4gz6LxdtJPK41OluBRuG3g1tMgiFFs+sUvN3DFdsE1YIDtFuiStQR7eR+ton4ml2+JBTFb5LyxHSmubGdiNEn7CZLRlaTiehQ17FhO+5z0QURS9Ey/UZAPEeEI8N/DSkjRGZ34sd6r2a7gO/Psev8BoRmv/thDHTxz4ZuY5b5s=" originalsrc="https://www.omg.org/spec/UML/2.5.1/" shash="D5ICIkpTCJXxPq+9xlsmP+d4npS+V+tqcyxA7Uom23gSXW35zVKHnm4pQNTX07/06zSvpgl97xy6KejdK/lZdBZ4+Y7k4Lgci5C0C726CUsgcaQEGVFJUlh41WRbCuYODxDZqlZBOiPsyEMrFWD5jkgxBicEGGVORnGN1OezDoA=" target="_blank">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%7Cbae78bda278e416d078a08dad64bd52a%7C43ba4fbcdc0a4269b50364f0363799d8%7C0%7C0%7C638057918448865431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T4QsvvUn1hhHB1w12KnBLQe3pfTQOMZg48Jcack6Oe4%3D&reserved=0</a><br>
<br>
or for MOF, you write:<br>
<br>
[MOF] Meta Object Facility, version 2.5.1<br>
<a href="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" originalSrc="https://www.omg.org/spec/MOF/2/5.1/" shash="pyl/sredsQBfdz5ZoX7Hm03/yVhHME6wEOpwS7zXwe6UjBE8gI9AqRRWjbg/A75prfWLBuI5gCQ0uqRwZsQWvGHJSpnI3dCkE04eipNFccUAZIeXtxVCrWoA0Q62/LBIvCCM7WMfnuJjv/2jOE1MDCCyZryP3ftbe00Zf3kRh8g=" originalsrc="https://www.omg.org/spec/MOF/2/5.1/" shash="CzIVZr2rtYq0GejR0NJlpZpDTLC1nm8sOuerwxllOXcukIf/CBujvC8FcIDGvVdIcb7iJqqOHm0SYMw06XbTBpanm7am7gazxtUe+21DXvk1uOFKZLDoRTufFZRzD0VmUxepMR2tXH1DY9GOviQn7lEjNvNFnXywBJevYqLaq78=" target="_blank">
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%7Cbae78bda278e416d078a08dad64bd52a%7C43ba4fbcdc0a4269b50364f0363799d8%7C0%7C0%7C638057918448865431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=naB%2BkGOKw4P50qi7FVUUNayZ6DXhDBSALmB9NJoRFvM%3D&reserved=0</a><br>
<br>
or for IDL, you write:<br>
<br>
[IDL] Interface Definition Language, version 4.2<br>
<a href="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" originalSrc="https://www.omg.org/spec/IDL/4.2/" shash="ceMTQ6kmEzhk51e8UhORC5/mXip+WRT8ooqryJgfJ6+h9iBM/zBGAbB0+6gnsbbgH/VUjBiFrLGWa2iFKmR08VWaXBPiRBThkaOs/mTRPTCL1p8p92zkQwQnjdFupY/WrinIbaUJh9XsMSUyI74f/njmRNdbMG+obujXFQk4cz8=" originalsrc="https://www.omg.org/spec/IDL/4.2/" shash="RTUBAL+9BJbG8MUKFLT/ljcWPSNjddG0v9Y1Ato2aP90cqD9b3b5DFwZiim1LftVZpYT/2vWAXre7dl2kQT+JTwrecXO3zhL/bj1EThH/lwtC9/8AKPU0ZYl7K2gcHEGNetj2IcgaDq/SJIraQAhIabVWrY6mTvzZPUunf8bJ5s=" target="_blank">
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.omg.org%2Fspec%2FIDL%2F4.2%2F&data=05%7C01%7Cspace%40omg.org%7Cbae78bda278e416d078a08dad64bd52a%7C43ba4fbcdc0a4269b50364f0363799d8%7C0%7C0%7C638057918448865431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y7JucjLKbHksPk2ClHaC%2BWl8QPdFrvTMu2aCkBTPb%2BM%3D&reserved=0</a><br>
<br>
Every of these references should be followed by a short paragraph arguing why<br>
submitters shall use this technology.<br>
<br>
I think this gives you the pattern. Extend this also for OMG-work-in-progress things<br>
you want to mention, but for these you cannot *mandate* the use, you need to write<br>
"Submitters are encouraged to {use | refer to} that-and-that technology", or something
<br>
along that line.<br>
<br>
Then your requirements...<br>
<br>
They need to be concise and precise. Each requirement must ask for just ONE thing.<br>
No big prosa expalantions within requirements, if there is need for explanations, that<br>
must go into 6.2 and the requirement just referencing it.<br>
<br>
Also, every requirement must have a unique identifier, not just a simple list number.<br>
Some RFPs use a simple "6.5.n" scheme, some use real identifiers like for example<br>
"MPIM01" for the first mandatory requirement ablut the PIM. Submitters must then<br>
refer to these requirements identification in section 0 of the submission and explain<br>
how the requirement was satisfied.<br>
<br>
Non-Mandatory Requirements are then either "6.6.m" or for example NMFeature03"<br>
for Non-Mandatory Feature 3.<br>
<br>
I think you got the pattern again.<br>
<br>
Then, Issues to be discussed:<br>
<br>
Don't ask for explaining how requirements are fulfilled.<br>
<br>
You must make the submitters explain complicated things, like how their solution<br>
is guaranteeing minimum QoS behavior, and so on.<br>
<br>
About your IPR mode.<br>
<br>
I mean it is your discretion, but I really don't understand what your motivation is<br>
to specify the fairly restrictive "RF Limited" IPR mode. It is my feeling that you
<br>
should a wide mix of proprietary and open-source solutions as responses. That<br>
means that the "Non Assert Covenant" IPR mode would be much appropriate.<br>
<br>
I hope you are not just want to write this RFP so that you can submit just your<br>
own solution, then protected by "RF Limited". That is not what the OMG stands<br>
for, and what the purpose of standardization is.<br>
<br>
I encourage you to consider "Non Assert Covenant". All new OMG specification<br>
tend to use this, and "RF L:imited" is only used if old, pre-IPR Policy license<br>
obligations from an older version of the technology exist.<br>
<br>
Finally, your time table is too tight. You need to relax it quite substantially. But almost<br>
every RFP has that problem initially. Remember, nobody within the OMG has been<br>
punshed for delivering eralier....<br>
<br>
Ok, this has been a lot. And this RFP needs a lot of more work. I suggest to <br>
work on it and plan for the Spring OMG meeting. Let me know if you need some<br>
help. <br>
<br>
Kind regards,<br>
<br>
Manfred<o:p></o:p></p>
</blockquote>
</div>
</div>
</body>
</html>