<font size=2 face="sans-serif">Dear John,</font>
<br><font size=2 face="sans-serif">Thanks a lot, I'll put JPL PS-3 on the
agenda. However, I am afraid but it is a consequence of the taken approach
that a CSTS Service Specification has this close relation to the CSTS Service
Specification Framework. No problem to be clear on that, but we cannot
allow the adoption of newer versions once they are available. This would
be like stating 'oh yes, this version of Word will work with any future
version of Windows once available...'.</font>
<br>
<br><font size=2 face="sans-serif">Best regards,</font>
<br><font size=2 face="sans-serif">Holger</font>
<br>
<br><font size=2 face="sans-serif">Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | S-431<br>
+49 6151 90 2233 | </font><a href=http://www.esa.int/esoc><font size=2 face="sans-serif">http://www.esa.int/esoc</font></a>
<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>,
"Wolfgang Hell" <wo_._he@t-online.de></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">03/03/2020 22:42</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">[Css-csts] Forward
Frame CSTS WG Review Package on CWE</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">"CSS-CSTS"
<css-csts-bounces@mailman.ccsds.org></font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3 face="sans-serif">CSTSWG colleagues ---</font>
<br><font size=3 face="sans-serif">I have been informed that the FF-CSTS
prototype testing has successfully concluded with no changes required of
the FF-CSTS specification. I have therefore put together a working group
review package and posted it to the CWE at URL:</font>
<br><a href="https://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/Future%20Services%20using%20Toolkit/Forward%20Frame%20CSTS/FF-CSTS-922x3r2.2-1200303-CSTSWG_Review.zip"><font size=3 color=#0082bf face="sans-serif"><u>https://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/Future%20Services%20using%20Toolkit/Forward%20Frame%20CSTS/FF-CSTS-922x3r2.2-1200303-CSTSWG_Review.zip</u></font></a>
<br><font size=3 face="sans-serif"> </font>
<br><font size=3 face="sans-serif">The zip file contains 3 files:</font>
<ol>
<li value=1><font size=3 face="sans-serif">An annotated version of the
FF-CSTS book, in which the annotation consists of Word markup balloons
that identify the reasons for the changes from the internationally-reviewed
Red Book version. Most of these references are to the RIDs that caused
them, but a few others refer to changes resulting in test compilations
if the ASN.1 modules and typo that were discovered along the way. When
the book is ready to go to the Secretariat for publication, these annotations
will of course be removed.</font>
<li value=2><font size=3 face="sans-serif">An updated copy of the RID resolutions.
Note at all RIDs and pseudo RIDs have been resolved, accepted by the WG,
and incorporated into the document except the following three, which all
stem from Peter Shames’ request to have the book more explicitly address
the role of the FF service in Delay-Tolerant Networking (DTN) and Pater’s
subsequent review of the document as a whole:</font>
<li value=3><font size=3 face="sans-serif">Pseudo RID JPL PS-1: This pseudo
RID documents Peter Shames’ request for an explicit discussion of the
role of the FF service in Delay-Tolerant Networking (DTN) configurations.
Proposed changes have already been drafted in the book. Those changes have
been accepted by the pseudo RID author. If and when the CSTSWG agrees with
the changes, pseudo RID JPL-PS-1 will be closed.</font>
<li value=4><font size=3 face="sans-serif">Pseudo RID JPL PS-2: This pseudo
RID documents multiple comments made by Peter Shames on the Red Book. Proposed
resolutions for all items in the pseudo RID have been generated, either
as changes that have already been drafted in the book or as explanations
of questions asked. All of the proposed resolutions have been accepted
by the pseudo RID author. If and when the CSTSWG agrees with the changes,
pseudo RID JPL-PS-2 will be closed.</font>
<li value=5><font size=3 face="sans-serif">Pseudo RID JPL PS-3: This pseudo
RID deals with the change in the CCSDS Blue Book “boiler plate” introduction
to the References sections of CSTS specifications. For reasons having to
do with the close synchronization of CSTS specification versions and CSTS
SFW versions, the introductory paragraph now prohibits subsequent versions
of the SFW from being used with any given issue of a CSTS specification.
This change in approach has elicited concern by Peter about the desirability
and feasibility of essentially maintaining multiple active versions of
the SFW book. I have copied the relevant portions of our email exchange
at the bottom of this email (below my signature). The most recent response
(today) from Peter is “I am willing to close out the comment, but only
if the CSS CSTS WG makes a commitment to a) making sure that this situation]
is made blazingly clear, and b) make a commitment to fixing this at the
soonest possible opportunity.“</font></ol><font size=3 face="sans-serif"> </font>
<br><font size=3 face="sans-serif">Pseudo RIDs JLP-PS-1 and JPL-PS-2 only
require the WG’s concurrence for their closer. However, JP-PS-3 requires
some thought on how to clarify the situation and how the WG will prioritize
updating the MD and TD books. </font>
<br><font size=3 face="sans-serif"> </font>
<br><font size=3 face="sans-serif">I would like to request that we put
pseudo-RID JPL-PS-3 on the agenda for next Thursday’s telecon. I have
included the relevant contents of the emails between Peter and myself in
the text of pseudo-RID JPL-PS-3. I would encourage WG members to read through
that pseudo RID before next week’s telecon so as many as possible of us
will have some understanding of the situation.</font>
<br><font size=3 face="sans-serif"> </font>
<br><font size=3 face="sans-serif">Thanks.</font>
<br><font size=3 face="sans-serif"> </font>
<br><font size=3 face="sans-serif">Best regards,</font>
<br><font size=3 face="sans-serif">John</font>
<br><font size=3 face="sans-serif"> </font>
<br><font size=3 face="sans-serif">EMAIL EXCHANGE BWTWEEN PETER SHAMES
AND JOHN PIETRAS</font>
<br><font size=3 face="sans-serif"> </font>
<br><font size=3 face="sans-serif"><b>Original Comment from Peter: Section
1.9 (References): Regarding the sentence “All other publications in the
list are subject to revision, and users of this document are encouraged
to investigate the possibility of applying the most recent editions of
the publications (other than the Specification Framework) indicated below.”
RID author commented “Is it really true that ALL of these other
references are suspect? Even the most recent of them?” </b></font>
<br><font size=3 face="sans-serif">Response (26 November 2019) This
is a variation of the standard boilerplate for all Blue Books, which is
”All publications are subject to revision, and users of this document
are encouraged to investigate the possibility of applying the most recent
editions of the publications indicated below” (CCSDS A20.0-Y-4 Cor. 1,
February 2015, 3.4.1.8 (a) (2)). Our CSTS modification (which will apply
to all CSTS specifications) calls out the fact that a given issue of a
CSTS spec is tied to a single issue of the Framework and so no version
of the Framework beyond the one explicitly cited can possibly be applicable
to a particular issue of the CSTS spec. </font>
<br><font size=3 face="sans-serif"><b>Reply from Peter (4 December 2019)
For sec 1.9 it was what I read as a peculiar shift of language that
bothered me. It is always that case the specs are only aligned with those
others that are current at the time of publication. This is not any different
for the Framework than for any other doc. And it is entirely possible that
a future change may be made to the Framework without necessarily changing
all of the other docs that use it. I think what is different here is that
this doc is explicitly tied to the version of the Framework that contains
the updates that are require to support FF-CSTS. I think you can just state
that somewhere in the doc.</b></font>
<br><font size=3 face="sans-serif">Pietras esponse to reply (24 February
2020) In response to the statement “I think what is different here
is that this doc is explicitly tied to the version of the Framework that
contains the updates that are required to support FF-CSTS.” That statement
is not exactly true, because although future versions of the Framework
could theoretically also be used by “this” version of the FF spec insofar
as the functionality defined therein doesn’t change for the procedures
that are used by FF, there are version-specific numbers that are embedded
in the SFW ASN.1 modules that increment with every version of the SFW and
the FF procedures are tied to the specific SFW version numbers. A CSTS
will work with *<b>only</b>* the version of the SFW that is specified in
the Reference Documents section. And that’s just not FF-CSTS: it’ll be
true for every CSTS. Plans for the next revision of the CSTS Guidelines
are to include that re-wording of the boilerplate for all CSTS specifications.
</font>
<br><font size=3 face="sans-serif">So it’s not that this is a one-off
situation for FF-CSTS, it’s something that has to be addressed for all
CSTS specifications. The WG chose to address it right up front, and to
explicitly clarify that the boilerplate statement “</font><font size=3>users
of this document are encouraged to investigate the possibility of applying
the most recent editions of the publications indicated below” </font><font size=3 face="sans-serif">does
not, and cannot, apply to the SFW. The feeling of the WG was that if this
was left “unchallenged” in the Reference Documents boilerplate the constraint
might still be overlooked even if it were stated somewhere else (later)
in the document.</font>
<br><font size=3 face="Courier New"> </font>
<br><font size=3 face="sans-serif"><b>Reply from Peter (2 March 2020):
What I am getting from this is that the WG has adopted an SFW and associated
standard versioning approach, if I understand it correctly, such that each
CSTS spec is tied to a specific version of the SFW. What this says
to me is that there is no stated policy for backwards compatibility such
that any future changes to the SFW would continue to be compatible with
earlier CSTS specs. If that is truly the case, and I can understand
situations where future changes might break that "rule", the
consequence would appear to be that the CSS (and the users of these specs)
will have to maintain ALL versions of the SFW forever. This seems
really cumbersome at best. Am I misunderstanding this?</b></font>
<br><font size=3 face="sans-serif"> </font>
<br><font size=3 face="sans-serif">Pietras Response to Reply (3 March 2020):
I think that you’ve got it right. However, there are a couple of additional
points that I should have made: </font>
<ol>
<li value=1><font size=3>Any new CSTS specification will always be written
citing the then-current version of the SFW. There will be no option for,
say, using the 2-issues-back version of the SFW as the basis of a CSTS.
</font>
<li value=2><font size=3>The WG’s intention is to update all CSTS specifications
to use the latest SFW ASAP (where the “soon” part is a function of available
resources and other commitments by the WG). So older version of the SFW
would be “active” only until all CSTS specs are aligned with the “current”
SFW, at which point all the older books are truly “silverized”. Note
that, like today, people may still choose to implement a silver version
of a specification anyway (e.g., for backward compatibility with the user
community) and this approach doesn’t address this issue any better or
worse than it’s addressed for other CCSDS Silver books.</font></ol><font size=3 face="sans-serif"> </font>
<br><font size=3 face="sans-serif">Case in point – the forthcoming FF-CSTS
book uses “features” of the forthcoming SFW-B-2 (and indeed it was the
need for these features that triggered many/most of the changes in SFW-B-2).
But SFW-B-2 also changes (and simplifies) some of the data structures used
not only by FF but also the already-blue MD and the on-the-verge-of-blue
TD services. MD and TD can be changed from the B-1 to B-2 SFW data structures,
and the WG intends to create projects to do so, but that will take time/resources
to modify the respective “older” CSTS specs. The already-published MD
book uses the SFW-B-1 data structures so it must reference SFW-B-1 or the
implementation would be broken. In the case of the not-yet-published TD
book (which also uses the SFW-B-1 data structures, the WG decided to go
ahead and publish it with reference to SFW-B-1 in order to get it out the
door, even though we know that it will have to be changed in the (near)
future (I think the idea is to update the MD and TD books concurrently).
</font>
<br><font size=3 face="sans-serif"> </font>
<ol>
<li value=1><font size=3>This may now seem like an administrative headache,
but hopefully the changes to core elements of the SFW will settle down
in the near future, and new versions of the SFW will only add new features,
procedures, and/or operations that don’t affect existing CSTSes. In that
(rosy) scenario, “updating” a CSTS spec to a new SFW will only involve
a short Technical Corrigendum that points to the latest SFW issue and relevant
paragraphs within that SFW issue. </font></ol><font size=3 face="sans-serif"> </font>
<br><font size=3 face="sans-serif">Maybe one way to think about this is
that, unlike the other references that CCSDS “encourages [users] to investigate
the possibility of applying the most recent editions”, the CSTSWG *<b>knows</b>*
what SFW version will work with the service as specified in the specification
and essentially tells users up front not to waste their time thinking about
it with respect to the SFW.</font>
<br><font size=3 face="sans-serif"><b> </b></font>
<br><font size=3 face="sans-serif"><b>Peter’s Response (3 March): I am
willing to close out the comment, but only if the CSS CSTS WG makes a commitment
to a) making sure that this situation is made blazingly clear, and b) make
a commitment to fixing this at the soonest possible opportunity.</b></font><tt><font size=2>_______________________________________________<br>
CSS-CSTS mailing list<br>
CSS-CSTS@mailman.ccsds.org<br>
</font></tt><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts"><tt><font size=2>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br>
<PRE>This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@esa.int).
</PRE>