[Css-csts] Comments on Buffered Data Delivery Procedure

[John Pietras]

Members of the CSTSWG --
I have uploaded to the CSTSWG CWE site a marked-up review PDF copy of
the Buffered Data Delivery Procedure section of the version 0.12 draft
of the Procedures Definition(filename
"BufferedDataDeliveryProcedure-0.12-JVPcomments.pdf"), at URL
http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/SLE%20Toolkit%20Pro
cedures/BufferedDataDeliveryProcedure-0.12-JVPcomments.pdf

I chose to provide this short PDF version of just the section that is
commented upon, rather than sending out the complete Word document. I
can easily email the reviewed Word document (or post it to the CWE) if
anyone wants it.

As you will see, the review comments address topics ranging from
editorial (e.g., varying uses of "notification", "NotifyInvocation
record", and other variants) to inconsistencies between the textual
specification of the behavior and the state table, to observations on
the proper relationship between specification of the procedure itself
and specification of the behavior of the Recorded Buffer (which is not
part of the procedure). 

I began to see these issues once I actively started trying to use the
procedure in the draft Real-time Radiometric Data service specification.
However, these issues are not specific to the application of the
procedure to the Radiometric service. 

As you have seen from emails that I have sent and to which Yves has
responded over the past weeks, I have identified other issues that are
particular to services (such as the Radiometric data service) that need
to differentiate among different types of content of the TRANSFER-DATA
invocation. In the case of the Radiometric data service, the procedure
needs to be able to distinguish between the TDM Data and TDM Metadata
content of the TRANSFER-DATA invocations, and ensure that the TDM
Metadata always gets through. This is not supported by the existing
Buffered Data Delivery Procedure, which in real-time mode treats any
data in a TRANSFER-DATA invocation as subject to discarding.

The main issue that I am struggling with is how to minimize the
extensions to and refinements of an existing procedure when the service
requires a significant level of service-unique processing of the data
being transferred by that procedure. In our current "a CSTS is composed
of procedures" paradigm, there is no alternative to specifying such
service-unique processing as part of the procedure(s) that comprise the
service. We cannot push such functionality off to the production
process, because production is independent of any single service
instance. What I am finding in the case of the Radiometric Data service
is that I am having to redefine major portions of the behavior of the
Buffered Data Delivery Procedure, to the point where I am wondering if
it is even legitimate to continue to call it a derivation of that
procedure. 

This has led me to begin thinking about a possible addition to our CSTS
model, which I'll call a "transfer service application" (at least for
the purposes of this message). In this modified CSTS model, the transfer
service application would exist between the procedures and production,
and serve to "massage" the data as necessary to translate between the
two. The transfer service application would be strictly an entity of the
individual service, not the toolkit. The potential advantage that I see
is that the extent of derivations of the procedures can be reduced by
allowing some (if not most) of service-specific customization to be
allocated to transfer service application instead of the procedures.
This will allow the standard toolkit procedures to be stable across a
wider range of services. 

I know that this is would be a rather radical alteration of the CSTS
approach, and I admit that I am still thinking it through. But I am
mentioning it now because I would like raise it as a possible topic of
discussion at the Crystal City meeting.

Best regards,
John

John Pietras
Global Science & Technology, Inc. (GST)
7855 Walker Drive
Suite 200
Greenbelt, Maryland, USA
20770-3239
Direct:   +1-240-542-1155
GST Main: +1-301-474-9696
Fax:      +1-301-474-5970