<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=utf-8">
<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">I posted this updated draftRFP as space/2022-12-01 at<o:p></o:p></p>
<p class="MsoNormal"><a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.omg.org%2Fcgi-bin%2Fdoc%3Fspace%2F2022-12-01&data=05%7C01%7Cspace%40omg.org%7Ca821f1de3a4546d28c8a08dad4a58215%7C43ba4fbcdc0a4269b50364f0363799d8%7C0%7C0%7C638056104554146037%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wxPwntwG3u%2Bkn3DN%2Fz9NvnuoaEvFEkg79%2BiNYqTRG3M%3D&reserved=0" originalSrc="https://www.omg.org/cgi-bin/doc?space/2022-12-01" shash="DSyVYUVO6HZ/i3TXBHfo/hCk6my8vxZo0SMq0NkcEUErfXyK4xqX3C9VPJOJ+AzTKAwUmIaLAvIY9Kqpwi49Um0TwL9Sb0CtAd+ouYtRP0xn3k4TM8bQ3CoE+DiiZcOmDt9fZ+/YKrKHFMDFVxFzL/6uNTmnxTobY5/M+HtuFHw=" originalsrc="https://www.omg.org/cgi-bin/doc?space/2022-12-01" shash="VXgYVMr52j0Lvq7NS0Lrtu8ZT6dGGvEL7CmSVHsa7fRqaRnLsevccqDXyrqE9gTwoVG1RQxxEiy9kSUDoIQol14ydUJ7Kqs0hq9A4wVteHuigj4JhdwRuM0OsJ+QPJc+c0LoIjJvtPVwfwBLiZDTzkdfySh566KSg7oPb0qywK4=">https://www.omg.org/cgi-bin/doc?space/2022-12-01</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Header and cover page have been updated accordingly<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> Friday, December 2, 2022 3:10 PM<br>
<b>To:</b> Manfred Koethe <koethe@88solutions.com><br>
<b>Cc:</b> Justin.Boss@kratosdefense.com; space@omg.org; ab@omg.org; eric.orgren@kratosdefense.com; Jason McC. Smith <jason@omg.org>; Jürgen Boldt <juergen@omg.org><br>
<b>Subject:</b> Re: Initial 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">An updated GDDI RFP is attached that addresses feedback received. Please review this updated version with track changes enabled for easier review.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">@Juergen, please upload this to the document store.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks all,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Justin Boss<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Nov 24, 2022 at 6:31 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>
Here is my initial AB review of the Ground Data RFP<br>
<br>
Reviewed document: space/2022-11-01<br>
<br>
To say it up-front: I strongly believe this RFP is not yet ready for issuance,<br>
and I'm not confident that all the problems could be fixed until the final<br>
AB review on December 8, 2022.<br>
<br>
There are two areas of problems with this RFP, which include even the<br>
question if there is a need for this RFP, or if there are already OMG<br>
technologies available that cover the described need. These are<br>
the problem areas I see:<br>
<br>
1. Formal appearance problems<br>
2. Technical problems<br>
<br>
1. Formal appearance problems<br>
<br>
The Objective section is fine.<br>
Section 6.1 is acceptable, it paints a reasonable picture of the needs,<br>
except that the Figure 1 lists a lot of things, but does not give a clear <br>
picture what you want to address with this RFP, and how.<br>
<br>
Section 6.2 is the section where an RFP is supposed to describe the <br>
solicited technology in plain words, but in this RFP Section 6.2 is very<br>
vague. Also, if you are really looking forward to define a new low-level<br>
TCP/IP protocol, then you are barking up the wrong tree. Defining <br>
low-level networking protocols is the domain of the IETF, protocols<br>
defined by OMG specifications are all Application-level Protocols.<br>
More regarding this under "2. Technical problems" below.<br>
<br>
Section 6.3 is very unclear and not in the propper format. You need to<br>
make clear references to specification required as mandatory readings<br>
by the prospective submitters. Each of these refferences shall have a<br>
short paragraph explaining the relevance, but withiout any prejudice.<br>
You are nowhere specifying what you really want. What technology <br>
shall be used to specify the "interfaces" (IDL? UML Data Models?<br>
MOF Metamodels? XML Schema? JSON Schema?...), therefore <br>
Section 6.3 lacks crucial references to one or more of those defining<br>
technologies.<br>
<br>
Section 6.4 has more references, but all references are very vague,<br>
except for the last four lines of Section 6.4.<br>
<br>
Section 6.5 Mandatory Requirements.<br>
It is very unclear what the RFP is really requiring here. All requirements<br>
are either too vague or even out of scope (like requirement #11) . It is<br>
unclear what technology is expected (IDL, UML, ....??) and if the RFP is <br>
just soliciting data formats, or data-describing metamodels.<br>
<br>
Section 6.6 Non-Mandatory Features.<br>
The RFP requests TCP already in the Mandatory Requirements, why <br>
including this again in the Non-Mandatory Features?<br>
<br>
Section 6.7 Issues to be discussed<br>
Only #3 makes sense here. This section is not for stating how requirements<br>
are satisfied, this section provides a forum for the submitters to argue why<br>
they choose a certain solution.<br>
<br>
Section 6.8 Evaluation Criteria<br>
Tere is only the default stuff listed here, but what are the technology-specifc<br>
criteria to evaluate one submission against another, if there are many? How<br>
will you judge if a submission is satifying the RFP at all?<br>
<br>
Section 6.10 IPR Mode<br>
Why RF-Limited? This ia an RFP for a new specification without history, wouldn't<br>
Non-Assert be more appropriate?<br>
<br>
Section 6.11 Time Table<br>
Your time table is way too agressive. You need to provide more time for initial and<br>
revised submission. You can always deliver earlier, nobody has been punished <br>
by the OMG for that...<br>
<br>
Now the more difficult part of my review:<br>
<br>
2. Technical problems<br>
<br>
Let me say upfront that I have past expereince in distributed systems and <br>
implementing high performance network stacks.<br>
<br>
I think your RFP should not try to invent yet another networking protocol, or<br>
even a new middleware technology. So forget about specifying a protocol<br>
directly IP, or even TCP level. With the current aim to make the low levels of<br>
networks as secure as possible, introducing a new protocol on that low level<br>
creates an unnecessary up-hill battle. An application-level protocol, if done<br>
right, can fulfill all your anticipated transfer rates, easily.<br>
<br>
I have a concern that you asked in one requirment for connection-less trasmission.<br>
This is the wrong approach, in my humble opinion. Connection-less streams are<br>
not neccessarily faster than well-designed connection-oriented streams, but <br>
take away all mechanisms of low-level (and therefore efficieint) error detection<br>
and handling. Connection-less streams may be fine for video image streams, <br>
where there is only little difference between one frame to the next (so you can <br>
recover fairly easily). But the lossyniess of connection-less streams is fatal for<br>
precious scientific data.<br>
<br>
In summary, what you should ask for in this RFP is the specification of a <br>
metamodel system describing the transferred data and embedded metadata,<br>
and leave the actual transmission to proven middleware, lilke for example DDS.<br>
In that respect you should read the "DDS Extension for Time-Sensitive Networking"<br>
submission, up for adoption at the Austin meeting this December. I think this <br>
technology provides you withe the searched-for rapid trasmisson capabilities.<br>
<br>
Then regarding the descriptive metamode, what is so wrong with wht C2MS already<br>
provides?<br>
<br>
In summary, this RFP needs a lot more discussion. Sorry.<br>
<br>
Kind regards,<br>
<br>
Manfred<o:p></o:p></p>
</blockquote>
</div>
</div>
</body>
</html>