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

Mon Jan 22 20:49:45 UTC 2018

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:
https://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/Future%20Services%20using%20Toolkit/Forward%20Frame%20CSTS/FF-CSTS-922x3-w-0_6-180122.doc

The great majority of the comments were easily understood and easy to put into the book. However, there were three comments that I think deserve some discussion and consideration at the WG level:

1.       Should we continue to use terminology adopted and adapted from the SLE Reference Model, or should we transition to terminology from the Space Communications Cross Support Architecture Description Document (SCCS ADD)? This topic is described in more detail under bullet (A) below.

2.       The current approach to handling the several configuration parameters that are defined as dynamically modifiable on the SFW is to have them initially configured by Service Management but to allow their values to be optionally respecified as part of the START invocation. Wolfgang suggests a simpler mechanism - don't include them in the initial configuration and required that the always be specified as part of the START. See item (d) below.

3.       The Service Object Identifiers Module annex currently assigns the OID to the functional resource for the FF service (ffCstsProvider) and its 3 immediate subtrees. How does this relate to the authority of the SANA registry to assign these OIDs? See item (K) below.

I have added these 3 topics to the Discussion Items slide set and poste the update:
https://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/Future%20Services%20using%20Toolkit/Forward%20Frame%20CSTS/ForwardFramesCstsDiscussionItems-180122.pptx

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.

H.      Section 8 (Forward Frame Service-Specific Versions of Service-Generic Parameters and Events). Accepted the corrections.

I.        Section 9 (Refinement of Definitions of Framework Parameters, Events, Directives, and Diagnostic Values Used by the Forward Frame Service). Accepted the corrections.

J.        Annex A (ICS Proforma). No comments on placeholder section.

K.      Annex B (Service Object Identifiers Module). Changes accepted.

Annex B includes (among other OIDs) the assignment of the OIDs for the ffCstsProvider FR type ({crossSupportFunctionalities 16}) and its three immediate subtrees (ffCstsProviderParametersId, ffCstsProviderEventsId, and ffCstsProviderDirectivesId). Wolfgang questions the assignment of these OIDs as part of this module will be permanent or eventually removed when the SANA Registry become formal. I would take this question one step further - since these are merely branches that are useless until the SANA Registry defines the concrete "leave" (parameters, events, and directives), does it serve any purpose to declare these OIDs in this module even temporarily? One argument for naming at least the classifiers in the FF CSTS book is that it provides the top-level  linkage between the Blue Book and the SANA Registry. We already do this at the lower levels by defining the classifiers that are to be used by FR parameters that correspond to the service management and read-only parameters of the FF service. Would it be sufficient to have in the FF service book a set of normative statements along the lines of:

"Each entity that provides an instance of the Forward Frame service shall be represented by a functional resource with the classifier ffCstsProvider."

"The Object Identifiers for the functional resource parameters for an entity that provides an instance of the Forward Frame service shall be registered under the  ffCstsProviderParametersId branch of the ffCstsProvider subtree."

Etc.

L.       Annex C (Procedure - Sequence-Controlled Frame Data Processing PDUs). Changes accepted.

M.    Annex D (Procedure - Buffered Frame Data Processing PDUs). Changes accepted.

N.     Annex E (Procedure - Master Throw Event PDUs). Changes accepted.

O.     Annex F (Forward Frame Service Procedure Parameters, Events, and Directives).  Changes accepted.

P.      Annexes G, H, and I - To Be Supplied sections - no comments.

Q.     Annex J - no comments.

R.      Annex K (Acronyms). Agree that the list must be updated prior to Red Book review.

S.       Annex L (Cross References to Cross Support Transfer Service Specification Framework). The MD-CSTS section was brought in as a placeholder. No work has been done on this section. I've deleted the MD-CSTS material to make this more obvious.

Best regards,
John

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