<font size=2 face="sans-serif">Hi John,</font>
<br><font size=2 face="sans-serif">I agree to what you say. In particular
the idea of getting the SFW stable is essential Peter has a very true point
here. The good thing is that this is in line with what we are doing, it's
just like you say, quite issues form the SFW B-1 had to be simply corrected.</font>
<br>
<br><font size=2 face="sans-serif">Let's discuss on Thursday.</font>
<br>
<br><font size=2 face="sans-serif">Best regards,</font>
<br><font size=2 face="sans-serif">Holger</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">"Holger.Dreihahn@esa.int"
<Holger.Dreihahn@esa.int></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">"CCSDS_CSTSWG
(css-csts@mailman.ccsds.org)" <css-csts@mailman.ccsds.org>,
"CSS-CSTS" <css-csts-bounces@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">04/03/2020 15:06</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">RE: [Css-csts]
Forward Frame CSTS WG Review Package on CWE</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3 face="Calibri">Hi, Holger. </font>
<br><font size=3 face="Calibri">Yes, I completely agree that a given version
(issue) of a CSTS Blue Book is tied to one and one only version of the
SFW. Peter’s valid concern is that if, say, we were to never update the
MD-CSTS book even after multiple updates of the SFW, then we could never
fully “silverize” SFW-B-1 and we would have concurrent active SFW Blue
Books. That would break the larger CCSDS version control paradigm. </font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">In order to not have to keep all previous
version of the SFW active, it would be necessary to (eventually) update
all existing CSTS specifications to the latest SFW version. That may take
some time (given available resources) but once all books have been updated
to or beyond a given version of the SFW, then all versions of the SFW older
than that given version can truly be considered archival. And in fact I
think that this is what we are already planning to do with the MD and TD
books – for the immediate future we will keep them tied to SFW-B-1 but
we intend to eventually update them to conform to SFW-B-2, at which point
the MD-CSTS-B-1, TD-CSTS-B-1, and SFW-B-1 “group” can collectively be
truly archived. (As I noted in my correspondence with Peter, that doesn’t
stop an organization from deliberately implementing a silverized version
of a CSTS and the corresponding procedures of its referenced SFW version,
but that kind of thing goes on today with other CCSDS Blue Books, too.)
</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">As I also noted to Peter, this may seem
like a lot of work (at least in the early years as we are working through
the SFW issues) but over time (sooner than later, I hope) the SFW updates
will slow (or stop), and when a new SFW version *<b>is</b>* issued it will
be to add new procedures for new CSTSes and leave the functionality used
by existing CSTSes unaffected. In such cases the updates of older CSTS
specifications will be simple Technical Corrigenda for each of the older
CSTS Blue Books that update the references to the SFW version and the ASN.1
module version numbers. </font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">I think we have an analogous situation
with the SLE suite of services, where we’ve created new versions of some
SLE specs only to keep them consistent with ASN.1 module specifications
of the SLE Blue Books that are updated for requirements changes.</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">I look forward to discussing this further
next week.</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">Best regards,</font>
<br><font size=3 face="Calibri">John</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri"><b>From:</b> Holger.Dreihahn@esa.int <Holger.Dreihahn@esa.int>
<b><br>
Sent:</b> Wednesday, March 4, 2020 2:33 AM<b><br>
To:</b> John Pietras <john.pietras@gst.com><b><br>
Cc:</b> CCSDS_CSTSWG (css-csts@mailman.ccsds.org) <css-csts@mailman.ccsds.org>;
CSS-CSTS <css-csts-bounces@mailman.ccsds.org>; Wolfgang Hell <wo_._he@t-online.de><b><br>
Subject:</b> Re: [Css-csts] Forward Frame CSTS WG Review Package on CWE</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Arial">Dear John,</font><font size=3 face="Calibri">
</font><font size=3 face="Arial"><br>
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><font size=3 face="Calibri">
<br>
</font><font size=3 face="Arial"><br>
Best regards,</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
Holger</font><font size=3 face="Calibri"> <br>
</font><font size=3 face="Arial"><br>
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=3 color=blue face="Arial"><u>http://www.esa.int/esoc</u></font></a><font size=3 face="Calibri">
<br>
<br>
<br>
</font><font size=3 color=#5f5f5f face="Arial"><br>
From: </font><font size=3 face="Arial">"John
Pietras" <</font><a href=mailto:john.pietras@gst.com><font size=3 color=blue face="Arial"><u>john.pietras@gst.com</u></font></a><font size=3 face="Arial">></font><font size=3 face="Calibri">
</font><font size=3 color=#5f5f5f face="Arial"><br>
To: </font><font size=3 face="Arial">"CCSDS_CSTSWG
(</font><a href="mailto:css-csts@mailman.ccsds.org"><font size=3 color=blue face="Arial"><u>css-csts@mailman.ccsds.org</u></font></a><font size=3 face="Arial">)"
<</font><a href="mailto:css-csts@mailman.ccsds.org"><font size=3 color=blue face="Arial"><u>css-csts@mailman.ccsds.org</u></font></a><font size=3 face="Arial">>,
"Wolfgang Hell" <</font><a href="mailto:wo_._he@t-online.de"><font size=3 color=blue face="Arial"><u>wo_._he@t-online.de</u></font></a><font size=3 face="Arial">></font><font size=3 face="Calibri">
</font><font size=3 color=#5f5f5f face="Arial"><br>
Date: </font><font size=3 face="Arial">03/03/2020
22:42</font><font size=3 face="Calibri"> </font><font size=3 color=#5f5f5f face="Arial"><br>
Subject: </font><font size=3 face="Arial">[Css-csts]
Forward Frame CSTS WG Review Package on CWE</font><font size=3 face="Calibri">
</font><font size=3 color=#5f5f5f face="Arial"><br>
Sent by: </font><font size=3 face="Arial">"CSS-CSTS"
<</font><a href="mailto:css-csts-bounces@mailman.ccsds.org"><font size=3 color=blue face="Arial"><u>css-csts-bounces@mailman.ccsds.org</u></font></a><font size=3 face="Arial">></font><font size=3 face="Calibri">
</font>
<div align=center>
<hr noshade></div>
<br><font size=3 face="Calibri"><br>
<br>
</font><font size=3 face="Arial"><br>
CSTSWG colleagues ---</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
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><font size=3 face="Calibri"> </font><font size=3 color=blue face="Calibri"><u><br>
</u></font><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="Arial"><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><font size=3 face="Calibri">
</font><font size=3 face="Arial"><br>
</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
The zip file contains 3 files:</font><font size=3 face="Calibri"> </font>
<ol>
<li value=1><font size=3 face="Arial">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><font size=3 face="Calibri"> </font>
<li value=2><font size=3 face="Arial">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><font size=3 face="Calibri">
</font>
<li value=3><font size=3 face="Arial">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><font size=3 face="Calibri">
</font>
<li value=4><font size=3 face="Arial">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><font size=3 face="Calibri">
</font>
<li value=5><font size=3 face="Arial">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="Arial"> </font><font size=3 face="Calibri">
</font><font size=3 face="Arial"><br>
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.
<br>
</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
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><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
Thanks.</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
Best regards,</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
John</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
EMAIL EXCHANGE BWTWEEN PETER SHAMES AND JOHN PIETRAS</font><font size=3 face="Calibri">
</font><font size=3 face="Arial"><br>
</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><b><br>
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><br>
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. <b><br>
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><font size=3 face="Calibri">
</font><font size=3 face="Arial"><br>
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. <br>
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 face="Calibri">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="Arial">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><font size=3 face="Calibri"> </font><font size=3 face="Courier New"><br>
</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><b><br>
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><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
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><font size=3 face="Calibri"> </font>
<ol>
<li value=1><font size=3 face="Calibri">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 face="Calibri">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="Arial"> </font><font size=3 face="Calibri">
</font><font size=3 face="Arial"><br>
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). <br>
</font><font size=3 face="Calibri"> </font>
<ol>
<li value=1><font size=3 face="Calibri">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="Arial"> </font><font size=3 face="Calibri">
</font><font size=3 face="Arial"><br>
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><font size=3 face="Calibri"> </font><font size=3 face="Arial"><b><br>
</b></font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><b><br>
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><font size=3 face="Courier New">_______________________________________________<br>
CSS-CSTS mailing list</font><font size=3 color=blue face="Courier New"><u><br>
</u></font><a href="mailto:CSS-CSTS@mailman.ccsds.org"><font size=3 color=blue face="Courier New"><u>CSS-CSTS@mailman.ccsds.org</u></font></a><font size=3 color=blue face="Calibri"><u><br>
</u></font><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts"><font size=3 color=blue face="Courier New"><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts</u></font></a><font size=3 face="Courier New"><br>
</font>
<br><font size=3 face="Courier New">This message is intended only for the
recipient(s) named above. It may contain proprietary information and/or</font>
<br><font size=3 face="Courier New">protected content. Any unauthorised
disclosure, use, retention or dissemination is prohibited. If you have
received</font>
<br><font size=3 face="Courier New">this e-mail in error, please notify
the sender immediately. ESA applies appropriate organisational measures
to protect</font>
<br><font size=3 face="Courier New">personal data, in case of data privacy
queries, please contact the ESA Data Protection Officer (</font><a href=mailto:dpo@esa.int><font size=3 color=blue face="Courier New"><u>dpo@esa.int</u></font></a><font size=3 face="Courier New">).</font>
<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>