[Css-csts] updated FF-CSTS incorporating Wolfgang's comments

[John Pietras]

CSTSWG colleagues ---
At last week's telecon we noted that Wolfgang had sent to me his comments on FF-CSTS draft 0.4, shortly after I had released version 0.5. I took the action to review Wolfgang's comments and incorporate them as appropriate in a new update (v0.6). I have done so, and the result is available at URL:


Here are my section-by-section comments on the results:

A.      Section 1 (Introduction). As I noted in last week's telecon, Section 1 is essentially as it has been for over a year: I have not yet attempted to make any systematic changes to section 1 and do not plan to do so until most of the rest of the book has  been completed to at least a first draft level. For now, section 1 will simply collect comments that have been made (so far by Tim and Wolfgang) and correct simple typos as they are identified.

However, Wolfgang has raised an important question in his comments - do we continue to use the terminology that evolved from the old SLE terminology (e.g., Cross Support Complex, Complex Management, MDOS, Space Element), or should we transition the book to the newer terminology of the Space Communications Cross Support Architecture Description Document (Provider Cross Support Service System, Provision Management, Earth User Node, Space User Node, respectively)? When we started the Framework, MD-CSTS, and TD-CSTS, the ADD had not yet been started so we used terms that were derived or inherited from the SLE Ref Model - e.g., "SLE Complex" became "Cross Support Complex".

We should probably transition to the SCCS ADD terminology, but that raises further questions with respect to the Framework and the MD-CSTS and TD-CSTS books. Should we try to "retrofit" them also? Fortunately, the uses of the terminology in all 3 books is pretty superficial and could probably be changed, since we're planning to update the Framework (and possibly the MD book?) at some time in the future, anyway. Alternatively, we could "straddle" both sets of terminology in the FF book - use the ADD term but when there is an older term for the equivalent in the Framework explain that. E.g., following the first reverence to "Provder CSSS" in the document, include the following Note:     NOTE -The term used for  Provider CSSS  in the CSTS Framework is "Cross Support Complex"."


B.      Section 2 (Overview of the FF-CSTS). Many (possibly most) of Wolfgang's comments may have been made moot by the rewrite of this section, and for those I did not attempt to include Wolfgang's individual comments in the update.

Wolfgang commented that the term "idle frames" should be replaced by "Only Idle Data (OID) frames". In rewriting section 2 for v0.5, I eliminated use of the term "idle frames" in favor of the more-general "idle data units", since in some cases the inserted data units could be frames and I others they could be CADUs. I'm not sure that that answers Wolfgang's concern. What we need is the term for the unit that the Forward AOS Sync and Channel Encoding function inserts when there are no user data-bearing frames or CADUs (depending on how the FF service is being used). This includes Insert data, since from the perspective of the Complex/Provider CSSS any Insert data must be put into the frame/CADU by the user, as there is no cross-support Insert service. Is it okay to call these inserted data units "idle data units", or do we need a different term?



C.      Section 3 (Composition of the FF-CSTS). Typos identified in tables 3-1 and 3-2 have been fixed. The other recommended changes have been accepted and included.

There are several cases in which the behavior in response to receipt of an out-of-sequence PDU included the statement that the PDU was to be "ignored",  which Wolfgang correctly pointed out that it was *not* ignored because it triggered an abort. He suggested that possibly the statement could be rephrased to say something like "the provider shall not respond to the invocation". I think that even though technically correct (where "respond" means sending a return of that same data type), in a more general context triggering an abort can be considered a "response". I substituted "discarding the invocation" for 'ignoring the invocation" instead. If that's acceptable, I'll remove Wolfgang's comments.



D.      Section 4 (Sequence-Controlled Frame Data Processing Procedure). Accepted the technical and editorial corrections. Changed the state table to use the same italicization convention as the SFW.

Wolfgang suggests that instead of the currently-document approach, which involves setting initial value for the input queue size parameter via service management and allowing the user to optionally reset the value as part of the START invocation; change it to make it mandatory to set the value as part of every START invocation. I have no strong feelings either way. We should discuss this in the FF splinter group.



E.       Section 5 (Buffered Frame Data Processing). Accepted the technical and editorial corrections. Changed the state table to use the same italicization convention as the SFW.



F.       Section 6 (Master Throw Event). Accepted suggested changes and typo fixes. Fixed the pagination problem.



G.     Section 7 (Setting of Service Management and Configuration Parameters Inherited from Framework Operations and Procedures). Accepted suggested changes and typo fixes. Fixed the pagination problem.

John Pietras
Principal Engineer
GST, Inc.
7855 Walker Drive, Suite 200
Greenbelt, MD 20770
240-542-1155

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20180122/d9e6689d/attachment.html>