[Ccsds-omg-liaison] [EXT] RE: Space Telecommunication Interface (STI) RFP - Prelim AB Review

[Char Wales]

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).

If a tweak to the title to give it less of a "domain" flavor is needed 
-- then go for it.

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...

Char

On 9/9/2019 8:31 AM, Kizzort, Brad (Peraton) (US Person) wrote:
>
> 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.
>
> Brad
>
> *From:* Jason Smith <jason at elementalreasoning.com>
> *Sent:* Sunday, September 8, 2019 10:40 PM
> *To:* Jeff Smith PhD <jeff.smith at macefusion.com>; mars at omg.org
> *Cc:* space at omg.org; ab at omg.org
> *Subject:* Space Telecommunication Interface (STI) RFP - Prelim AB Review
>
> Greetings all!
>
> 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.
>
> Some general notes before getting into specifics…
>
> 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.)
>
> 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?
>
> *Introduction: *
>
> This seems straightforward, build on SWRadio to add Space specific 
> solutions.  Got it.
>
> *6.1: Problem statement:*
>
> pg 18:
>
> Paragraph 1, line 11: The OMG originally commercialized?  I don’t 
> think we’re supposed to do that. “standardized” “developed” “published”…
>
> 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.
>
> pg 19:
>
> 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.
>
> “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.
>
> Under ‘Spacecraft Resource Constraints’: “An item limiting […] is the 
> available resources …”  Perhaps ‘property’ instead of ‘item’, 
> “Properties limiting […] are the available resources…”
>
> pg 20:
>
> 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.
>
> *6.2: Scope:*
>
> pg 21:
>
> 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…)
>
> “Submitters shall provide responses that not only respond to STRS 
> specific requirements […]” Okay, so are the STI requirements a 
> *superset* of STRS requirements?
>
> “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.
>
> 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.
>
> *6.3.1: Relationship to OMG specs*
>
> 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.
>
> Please provide a proper Appendix A with full references, and then 
> refer to those references here for the discussions.
>
> *6.3.2: Other OMG Docs and WIP:*
>
> 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.
>
> *6.4: Related non-OMG:*
>
> 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.
>
> *6.5: Mandatory Reqs:*
>
> *6.5.1 General *
>
> [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.
>
> [5]: “The STI response…”  ->  “The STI proposed submission”
>
> *6.5.2 Compliance Points*
>
> What is the plan for proof of compliance, if any?
>
> *6.5.3 Networking*
>
> [1] I assume the multi-mission mandatory req is to be determined 
> qualitatively?
>
> [9] Any guidance on kinds of performance metrics, as you did in [8]?
>
> *6.5.4 Security*
>
> “C2” is not defined in the document.  Add to the Appendix A.2 Glossary.
>
> *6.6: Non-Mandatory Features:*
>
> *6.6.2 Interface*
>
> 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’?
>
> *6.6.3 Functional*
>
> [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?
>
> *6.7: Issues to be discussed: *
>
> [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.
>
> *6.8: Evaluation Criteria*
>
> Are there any plans for defining ‘effectiveness’ or is it to be 
> qualitative assessment?
>
> 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.
>
> *6.11: Timetable: *
>
> 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.
>
> *A.1: References*
>
> 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:
>
> “<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.>”
>
> *A.2: Glossary:*
>
> Add ‘C2’ as per 6.5.4
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/ccsds-omg-liaison/attachments/20190910/f7376113/attachment-0001.html>