<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">Greetings all!</div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">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.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">Some general notes before getting into specifics…</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">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.)</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">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?</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><b class="">Introduction: </b></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">This seems straightforward, build on SWRadio to add Space specific solutions. Got it.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><b class="">6.1: Problem statement:</b></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">pg 18:</div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">Paragraph 1, line 11: The OMG originally commercialized? I don’t think we’re supposed to do that. “standardized” “developed” “published”…</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">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. </div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">pg 19:</div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">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.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">“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.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">Under ‘Spacecraft Resource Constraints’: “An item limiting […] is the available resources …” Perhaps ‘property’ instead of ‘item’, “Properties limiting […] are the available resources…”</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">pg 20: </div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">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.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><b class="">6.2: Scope:</b></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">pg 21: </div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">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…)</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">“Submitters shall provide responses that not only respond to STRS specific requirements […]” Okay, so are the STI requirements a *superset* of STRS requirements?</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">“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.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">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.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><b class="">6.3.1: Relationship to OMG specs</b></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">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.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">Please provide a proper Appendix A with full references, and then refer to those references here for the discussions.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><b class="">6.3.2: Other OMG Docs and WIP:</b></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">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.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><b class="">6.4: Related non-OMG:</b></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">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.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><b class="">6.5: Mandatory Reqs:</b></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><b class="">6.5.1 General </b></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">[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.</div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">[5]: “The STI response…” -> “The STI proposed submission”</div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><b class="">6.5.2 Compliance Points</b></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">What is the plan for proof of compliance, if any?</div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><b class="">6.5.3 Networking</b></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">[1] I assume the multi-mission mandatory req is to be determined qualitatively?</div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">[9] Any guidance on kinds of performance metrics, as you did in [8]?</div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><b class="">6.5.4 Security</b></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">“C2” is not defined in the document. Add to the Appendix A.2 Glossary.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><b class="">6.6: Non-Mandatory Features:</b></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><b class="">6.6.2 Interface</b></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">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’?</div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><b class="">6.6.3 Functional</b></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">[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?</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><b class="">6.7: Issues to be discussed: </b></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">[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.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><b class="">6.8: Evaluation Criteria</b></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">Are there any plans for defining ‘effectiveness’ or is it to be qualitative assessment?</div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">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.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><b class="">6.11: Timetable: </b></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">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.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><b class="">A.1: References</b></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">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:</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">“<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.>”</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><b class="">A.2: Glossary:</b></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">Add ‘C2’ as per 6.5.4</div></body></html>