<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000066" bgcolor="#FFFFFF">
<font face="Calibri">MARS has worked on RFPs in collaboration with
other Task Forces before, including Domain & Platform (e.g.
the IEF RFPs have been issued from MARS but worked on
collaboratively with C4I, the DDS Security RFP was issued from
SysA but worked on collaboratively with MARS).<br>
<br>
If a tweak to the title to give it less of a "domain" flavor is
needed -- then go for it.<br>
<br>
However -- as I recall -- the rationale for doing this RFP from
MARS vice Space had to do with the fact that the SNC WG is in
MARS. And it just seemed to make sense. Also -- Telecoms --
while that TF existed -- was a PTF.. not a DTF...<br>
<br>
Char<br>
</font><br>
<div class="moz-cite-prefix">On 9/9/2019 8:31 AM, Kizzort, Brad
(Peraton) (US Person) wrote:<br>
</div>
<blockquote type="cite"
cite="mid:32619_1568032568_5D764738_32619_34_10_SN6PR09MB30057F4A6A33525A6A3AEB56CFB70@SN6PR09MB3005.namprd09.prod.outlook.com">
<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;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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]-->
<div class="WordSection1">
<p class="MsoNormal">Since Space DTF keeps getting mentioned, I
thought I would respond. Jeff Smith, et al, have kept Space
DTF informed on the progress of this RFP. One of the major
reasons we haven’t taken it on as a TF is that most of the
CORBA/IDL/SCA expertise we would need is in MARS. I am not
opposed to having it proposed as a domain specification, but
it is likely the evaluation, feedback, and revision would be
mostly the same people that are bringing it forward in MARS,
so at a minimum, it would have to proceed jointly as a domain
RFP. The largest area of overlap with other domains and the
reason for a platform rather than domain specification would
be the area of Disruption Tolerant Networking, which is
applicable across robotics, IoT, mobile communications, etc.
Space has a slight advantage that many communication
disruptions can be predicted and planned due to physics, but
DTN is definitely applicable to many domains, so a platform
specification may be the best place. Perhaps a title change
would help with acceptance as a platform RFP and
specification.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Brad<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Jason Smith
<a class="moz-txt-link-rfc2396E" href="mailto:jason@elementalreasoning.com"><jason@elementalreasoning.com></a> <br>
<b>Sent:</b> Sunday, September 8, 2019 10:40 PM<br>
<b>To:</b> Jeff Smith PhD
<a class="moz-txt-link-rfc2396E" href="mailto:jeff.smith@macefusion.com"><jeff.smith@macefusion.com></a>; <a class="moz-txt-link-abbreviated" href="mailto:mars@omg.org">mars@omg.org</a><br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:space@omg.org">space@omg.org</a>; <a class="moz-txt-link-abbreviated" href="mailto:ab@omg.org">ab@omg.org</a><br>
<b>Subject:</b> Space Telecommunication Interface (STI)
RFP - Prelim AB Review<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Greetings all!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This is my preliminary AB feedback report
on the Space Telecommunication Interface (STI) RFP:
mars/19-08-02. I have not conferred with colleagues, and
this does not preclude later comments.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Some general notes before getting into
specifics…<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Like a good scotch this is bold, complex,
and a little hard to define. Luckily, I like scotch,
because the lack of clear definition here is a bit hard to
swallow in a few places, which I will go into later. I
don’t believe it’s unfixable, however. Overall, I like the
goal and the direction, it builds on existing specifications
(not always clearly), and goes into new territory. (I
really wanted to say ‘frontiers’ here, but that was a bit
too on the nose.)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">But first, a question… why MARSPTF and
not SpaceDTF? It appears as if it could fit in either due
to the middleware aspects, but wondering why the choice of
the *platform* TF when the domain TF seems to be a much
better fit? Are there areas outside of Space domain that
this would be applicable? Has the SpaceDTF been given a
chance to weigh in?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b>Introduction: </b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">This seems straightforward, build on
SWRadio to add Space specific solutions. Got it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b>6.1: Problem statement:</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">pg 18:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Paragraph 1, line 11: The OMG originally
commercialized? I don’t think we’re supposed to do that.
“standardized” “developed” “published”…<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Ah, here’s my concern popping up. Last
paragraph pg 18 under Figure 1, flowing into page 19: “Even
though the SWRadio specification defines radio […] it does
not address key communications and platform requirements
imposed by the space domain sufficiently.” That makes me
think SpaceDTF if this is Space specific. To be clear, this
is not a showstopper if all have agreed that MARS is the
place to put it, it just seems like an odd choice from this
vantage. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">pg 19:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">This is exacerbated by the end of that
same paragraph: “The extent of reuse of the existing SWRadio
Profile will be up to the submitters.” If using this
SWRadio Profile is not required… is it just to be considered
informative? If so, then this is a further step away from a
platform solution to a domain solution, and SpaceDTF should
be at least signing off on this. Again, if there is
communication and agreement to place it here for whatever
reason, the concern is waived.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">“This RFP is intended to address issues
with the following elements:” —> “This RFP is intended to
solicit submissions that address issues with the following
elements:” The RFP doesn’t address the issues. It states
them.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Under ‘Spacecraft Resource Constraints’:
“An item limiting […] is the available resources …” Perhaps
‘property’ instead of ‘item’, “Properties limiting […] are
the available resources…”<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">pg 20: <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Space Waveforms:“The architecture will
have applicability greater than 2 GHz.” I would think that
a sliding scalability (think log) would be more important
here than a declaration of frequency width. kHz resolution
at 10MHz is (arguably) more important than kHz resolution at
tens of GHz.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b>6.2: Scope:</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">pg 21: <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Normally there’s a comment about not
using color in diagrams unless absolutely necessary, but
that kind of goes out the window with Figure 1, so I’ll let
this one pass. Unfortunately this is also where my
understanding of how the SWRadio, SSRC, STRS and STI are
supposed to interact, fell down, scraped its knee, and
wanted a lollipop. (Again, the prevalent use of an
unmodified ‘Space’ descriptor here makes me wonder about the
TF placement…)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">“Submitters shall provide responses that
not only respond to STRS specific requirements […]” Okay, so
are the STI requirements a *superset* of STRS requirements?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">“Examples of benefits’ isn’t scope of
proposals, it’s end results. I would think this would be
more suitable in Sec 6.1 explaining why this is necessary as
a proposal.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This section is really unclear to me.
The introduction was fine, and it seemed to lay out a
sensible roadmap. Section 6.1 laid out the case for the
constraints quite well, I was expecting a scope and
requirements that hit on those issues while building on
SWRadio. Instead, it’s a conceptual frappé. I would hope
that it is clear to those versed in the art here, but to my
external reviewer sensibilities, I honestly have no idea
what you expect to have submitted. That is a problem.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b>6.3.1: Relationship to OMG specs</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">This is where I have a bit of an issue,
and it is procedural, not content. You have created a
pseudo-reference list here, and back in Appendix A (which is
intended to be a formal reference list), you simply refer
back here. That won’t do. References are intended to
provide an archival snapshot in time on how to obtain
specific information. These discussions of the OMG specs do
not, they simply have a bracketed acronym prefixed to them.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Please provide a proper Appendix A with
full references, and then refer to those references here for
the discussions.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b>6.3.2: Other OMG Docs and WIP:</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">As with 6.3.1. Provide references in
Appendix A, and refer to them here. I am curious though,
why are SysML and UML listed here, and not under 6.3.1?
This section is for documents and works in progress that
have not yet been adopted. If you are referring to versions
of SysML and UML that are still in the works, then please
note that and change the URLs appropriately to point to the
specific documents, not just the home page for the spec.
That should only be used if you don’t care which version of
the spec is used or referred to, unless you note “use
current version as of the date of this document”. Same goes
for 6.3.1. above - refer to a specific version if it
matters, note ‘current as of this date’ if not.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b>6.4: Related non-OMG:</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">ALSO as with 6.3, and you forgot to call
back to Section 6.4 in Appendix A completely. Appendix A
isn’t just for OMG items, it’s for anything referred to in
this document that is not already included in Appendix B.
Luckily, you’re a lot closer to proper references here.
Copy and paste them down to Appendix A, then discuss why
each one is included here.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b>6.5: Mandatory Reqs:</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b>6.5.1 General </b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[3]: This is really asking for a
*hardware* architecture specification? What level of
granularity? SysML or something more like VHDL? It is
unclear if the requested STI HID API is a metamodel for
defining HIDs (“As part of a radio delivery, the radio
supplied is require to provide a HID…”), or a specific HID.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[5]: “The STI response…” -> “The STI
proposed submission”<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b>6.5.2 Compliance Points</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">What is the plan for proof of compliance,
if any?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b>6.5.3 Networking</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[1] I assume the multi-mission mandatory
req is to be determined qualitatively?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[9] Any guidance on kinds of performance
metrics, as you did in [8]?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b>6.5.4 Security</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">“C2” is not defined in the document. Add
to the Appendix A.2 Glossary.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b>6.6: Non-Mandatory Features:</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b>6.6.2 Interface</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I’d be curious to see how the STI API
bridges with these COTS interfaces. Are there established
interfaces you have in mind, or is this literally ‘if you
can build a bridge to a COTS system, that’s a plus’?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b>6.6.3 Functional</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[9] Secure transmissions is a nicety? I
thought you had a whole section above in 6.5.4 that talked
about how it was mandatory. Clarify the two situations?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b>6.7: Issues to be discussed: </b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[3] POSIX alternatives? This appears
nowhere else in the document, other than the reference. Can
you elaborate on the need/reason for this? It just comes
out of left field.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b>6.8: Evaluation Criteria</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Are there any plans for defining
‘effectiveness’ or is it to be qualitative assessment?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I’m surprised that ‘issues to be
discussed’ is not higher on the list, given that the issues
in 6.7 cover most of the scope.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b>6.11: Timetable: </b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I can only assume from the *VERY* rapid 6
months (and only three to LOI) that there is at least one
implementation in the wings, otherwise this is an extremely
compressed timeline for a spec of this complexity.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b>A.1: References</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Create a proper reference list for 6.3.1,
6.3.2, and 6.4. The template provided in ab/19-07-01 states
the following for Appendix A, please follow it:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">“<Note to RFP Editors: Insert any
references specific to this RFP that are referred to in the
Objective Section, Section 6 and any additional sections in
the same format as in Section B.1 and in alphabetical order
in this section.>”<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b>A.2: Glossary:</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Add ‘C2’ as per 6.5.4<o:p></o:p></p>
</div>
</div>
</blockquote>
<br>
</body>
</html>