[Css-csts] Another "RID" on the CSTS SFW

[John Pietras]

Wolfgang,
Your TD-CSTS comment about when the delivery of tracking data terminates in the complete delivery mode caused me to review the specification of the Buffered Data Delivery procedure. As a result, I believe that there is an inconsistency (or at the least, an ambiguity) in the specification of when the 'end of data' notification is to be sent.


A)     4.5.4.2.2.2.1 (c) (1) states "the conditions triggering the 'end of data' insertion shall be defined by the service using that procedure or by the derived procedure".


B)      However, 4.5.3.2.10 states "In case the generated data contains a generation time that is later than the stop generation time in the START invocation, an 'end of data' notification shall be generated
and inserted into the return buffer" and 4.5.3.2.11 states "Further conditions triggering the 'end of data' notification shall be defined by the derived procedure."


Point (A) implies that all triggers of 'end of data' must be defined by the derived services, whereas (B) defines a required use of the 'end of data' notification (that is, when the timetags of the data/invocations in the Recording Buffer exceed the stop generation time) and allows for derived services to define additional cases. These various requirements ned to be reconciled, e.g., by modifying 4.5.4.2.2.2.1 (c) (1) to acknowledge the Framework-defined requirement for inserting an 'end of data'.



Note that 4.5.3.2.10 provides a Framework requirement for inserting an 'end of data', but it only applies to cases where stop generation time has a non-null value. That covers the cases of complete delivery mode (which requires a non-null stop generation time) and real-time delivery mode where a non-null stop generation time is provided. Services that need an 'end of data' to be generated when the procedure is in real-time mode and stop generation time is null still need to refine the behavior of the (derived) procedure to specify the condition(s) under which the 'end of data' is to be generated.

Finally, in looking at the pertinent paragraphs I also stumbled across a couple of editorial-level corrections that should be made:

1)      4.5.3.5 (a) states "it shall stop inserting TransferDataInvocation and NotifyInvocation invocations into the return buffer". This should either be "it shall stop inserting TransferDataInvocations and NotifyInvocations into the return buffer" or "it shall stop inserting TRANSFER-DATA and NOTIFY invocations into the return buffer" (the latter form seems to be used more in the rest of the section).

2)      4.5.3.5 (b) states " it shall immediately build from the return buffer contents a ReturnBuffer PDU and shall keep attempting to pass that invocation to the underlying communications service until it is accepted." "... pass that invocation ..."  should be "...pass that ReturnBuffer PDU ...".

Best regards,
John

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