<font size=2 face="sans-serif">Dear John,</font>
<p><font size=2 face="sans-serif">We can certainly bring this point to
discussion in the next WG Telecon on Thursday.</font>
<p><font size=2 face="sans-serif">My first thought is that, whenever something
gets handled by Service Management, it becomes rather “static”. This
approach should be taken for any characteristics of a service that holds
for the whole mission. </font>
<br><font size=2 face="sans-serif">Assume the parameter “minimum retention
period” gets assigned by SM to the TD CSTS Service Instance. In
case a User needs to change that value the only way out is to disconnect
from the presently active Service Instance, create a new SI with the desired
value, activate the SI, and connect to it.</font>
<br><font size=2 face="sans-serif">If instead one envisages a more dynamic
behaviour, it would be preferable to leave the handling of the parameters
to the Service itself ( e.g. the value can be queried and can be
configured by means of a directive). </font>
<p><font size=2 face="sans-serif">The next point I have is: shall a Provider
(typically a Ground Station) manage one such buffer per each supported
mission, and shall therefore foresee that set of parameter for each buffer,
or will there be a unique buffer? </font>
<p><font size=2 face="sans-serif">Are the above issues something we should
address with the NAV experts?</font>
<p><font size=2 face="sans-serif">We’ll brainstorm about it at the telecom.</font>
<p><font size=2 face="sans-serif">Kind regards,<br>
Margherita</font>
<p><font size=2 face="sans-serif">--------------------------------------------------------------<br>
</font><font size=1 color=#00a1e0 face="Verdana"><b>Margherita di Giulio</b></font>
<br><font size=1 color=#5f5f5f face="Verdana">Ground Station Back-end Section
(HSO-GIB)<br>
</font>
<br><font size=1 color=#5f5f5f face="Verdana"><b>European Space Agency
ESA/ESOC</b><br>
Robert-Bosch-Str. 5<br>
D-64293 Darmstadt - Germany<br>
Tel: +49-6151-902779<br>
e-mail: Margherita.di.Giulio@esa.int</font><font size=1 color=#5f5f5f face="sans-serif"><br>
<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"John Pietras"
<john.pietras@gst.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"CCSDS_CSTSWG
(css-csts@mailman.ccsds.org)" <css-csts@mailman.ccsds.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">29/02/2016 22:14</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">[Css-csts] tracking
data recording buffer retention issues</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">css-csts-bounces@mailman.ccsds.org</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=2 face="Calibri">CSTSWG colleagues ---</font>
<br><font size=2 face="Calibri">I have been making the final synchronizations
between the TD-CSTS and the latest SFW. I believe that I have made almost
all of the necessary adjustments, with the following exceptions.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">The current TD-CSTS specifies that the
following be established by Service Management:</font>
<br><font size=2 face="Calibri">a. the size of the
recording buffer; </font>
<br><font size=2 face="Calibri">b. minimum period that
the TDM Recording Buffer is required to retain the stored data before it
is automatically purged; and</font>
<br><font size=2 face="Calibri">c. overflow policy
that shall be applied when new tracking data is available to be stored
but the TDM Recording Buffer is full</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">The current TD-CSTS goes on to state that
the parameter that specifies the size of the recording buffer (</font><font size=2 face="Courier New">tdmRecordingBufferSize)</font><font size=2 face="Calibri">is
queriable.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">The latest (and we hope final, at least
for now) SFW specifies that that every CSTS that a “Functional Resource
Type representing a recording buffer shall have a queriable </font><font size=3 face="Courier New">recording-buffer-size</font><font size=2 face="Calibri">
parameter that specifies the storage capacity of the recording buffer”
(CSTS SFW 4.5.7.9). However, the CSTS SFW is mute on the subject of how
the recording buffer size is configured. </font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">Also, the NOTE under 4.5.7.5 (a) states
“The time span over which data is retained in the recording buffer, the
policy for deleting data from the recording buffer, and the conditions
under which the recording buffer begins to accept data following an overflow
condition are outside the scope of this Recommended Standard. In general,
service provider and service user will agree on a data custody transfer
protocol.”</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">Regarding the recording buffer size, I
propose that we continue to have the TD-CSTS specify that </font><font size=2 face="Courier New">tdmRecordingBufferSize</font><font size=2 face="Times New Roman">
</font><font size=2 face="Calibri">is not only the parameter by which the
buffer size is queried, but also the parameter by which is it configured.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">Regarding the minimum retention period
and overflow policy, the question that I have is whether stating that the
minimum retention period and overflow policy are “established by Service
Management” is consistent with the SFW’s treatment of these topics, which
says that it is outside the scope of the SFW, other than to say that that
the service user and service provider will come to some agreement. Even
though the TD-CSTS doesn’t say how Service Management establishes them,
our general concept has been that by saying something is handled by Service
Management means that the CSSMWG is expected to establish some standard
way for doing so. Are we okay with such an approach, or should we soften
the wording even in the TD-CSTS to match the SFW approach, such that such
decisions could even be made outside the scope of CCSDS-standardized Service
Management?</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">If we have a few minutes to discuss this
during this coming Thursday’s telecon, I would appreciate it. I would
like to be able to go into the Cleveland meeting with as clean and final
a TD-CSTS as possible.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">Thanks.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">Best regards,</font>
<br><font size=2 face="Calibri">John </font>
<br><font size=2 face="Calibri"> </font><tt><font size=2>_______________________________________________<br>
Css-csts mailing list<br>
Css-csts@mailman.ccsds.org<br>
</font></tt><a href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts"><tt><font size=2>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br><PRE>This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
</PRE>