<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi Holger,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Yes, I do tend to read a lot of the email traffic for certain WGs that I see as critical to forward progress. CSTS is on my list (for better or worse).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I completely get the point that you are making about "<span style="font-size:10.0pt;font-family:"Arial",sans-serif">very practically I am also scratching my head how update ESA's B-1 implementation of the CSTS Specification Framework to
B-2 in a way that both, B-1 and B-2 are supported</span> ". This is a case of what a colleague of mine likes to call "eating our own dog food". We have to make the standards and then we get to put on the other hat of trying to use them to get a real task
done. That's the best measure, IMHO, of whether we, as standards developers, have done our jobs well, so I congratulate you. An at that point I also offer my condolences, sometimes we make real trouble for others (and ourselves).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">You seem to be saying that the choice of the ASN.1 technology platform is both a blessing and a curse in this regard. I can only assume that that is because the use of a compiler to do automatic translation from the ASN.1 abstraction into
code results, as it must, in automatically generate, obscure but unique, names for variables, functions, etc, etc such that there is not any sort of parallel constructions that can easily be recognized in the generated code between the instances generated
from B-1 and that generated from B-2. Right?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Granted the .doc and .docx are not directly compatible, but it is possible to have a tool that reads both formats and that can convert from one to another. Great. But what MS did, in their infinite wisdom, is to have versions of .doc
(1997, 2000, 2007) that were subtly different, and then to drop all support for the earlier versions from the tool that retained the .doc 2007 and .docx 2013 compatibility. That is the insidious part. Those older files are still .doc files, but the tool
no longer accepts them. I think we all want to avoid the equivalent of that in our CCSDS work.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">My push here (and my hope in pushing for the SFW approach in the first place) was exactly to avoid that "<span style="font-size:10.0pt;font-family:"Arial",sans-serif">I am already complaining that I need to support 5 different versions
of SLE in one implementation" outcome. I do not think we have gotten there quite yet with CSTS SFW, but maybe we are now close.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks, Peter<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">"Holger.Dreihahn@esa.int" <Holger.Dreihahn@esa.int><br>
<b>Date: </b>Wednesday, March 4, 2020 at 11:20 PM<br>
<b>To: </b>Peter Shames <peter.m.shames@jpl.nasa.gov><br>
<b>Cc: </b>CSTS-WG <css-csts@mailman.ccsds.org>, CSS-CSTS <css-csts-bounces@mailman.ccsds.org>, John Pietras <john.pietras@gst.com><br>
<b>Subject: </b>Re: [EXTERNAL] Re: [Css-csts] Forward Frame CSTS WG Review Package on CWE<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Ho Peter,</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Nice to hear from you, you really read these emails - very good! I think you have a point, and very practically I am also scratching my head how update ESA's B-1 implementation of the CSTS Specification
Framework to B-2 in a way that both, B-1 and B-2 are supported. Which leads my thinking in a direction that at the end, users only cares about what an implementation of a standard supports, not so much if a standard itself is backward compatible.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Of course you are fully right that we should change standards backward compatible if we can. And believe me, that is one of my concerns. However, for the CSTS Services this is really a particular
case where I think that with the chosen (ASN.1) technology and all the relations between a CSTS Service Specification and the CSTS Specification Framework, adding another dimension, namely the applicability of newer CSTS Specification to a CSTS Service, would
render this unusable. It would be simply too complex, both to specify and to understand.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Coming back to the word example, I think that is what I talk above. For instance the docx format is really differently specified than the old doc format. Still, an implementation can open both. Specification
of the new format (docx) is not backward compatible, the implementation is. BTW, I am not a big Microsoft fan, but I think what they provide in terms of backward compatibility is outstanding. I am already complaining that I need to support 5 different versions
of SLE in one implementation...</span> <br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Best regards,</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Holger</span> <br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | S-431<br>
+49 6151 90 2233 | </span><a href="http://www.esa.int/esoc"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">http://www.esa.int/esoc</span></a>
<br>
<br>
<br>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#5F5F5F">From: </span><span style="font-size:7.5pt;font-family:"Arial",sans-serif">"Shames, Peter M (US 312B)" <peter.m.shames@jpl.nasa.gov></span>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#5F5F5F">To: </span><span style="font-size:7.5pt;font-family:"Arial",sans-serif">"Holger.Dreihahn@esa.int" <Holger.Dreihahn@esa.int>, "EXTERNAL-Pietras, John V (US 332C-Affiliate)" <john.pietras@gst.com></span>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#5F5F5F">Cc: </span><span style="font-size:7.5pt;font-family:"Arial",sans-serif">"CSS-CSTS" <css-csts-bounces@mailman.ccsds.org>, "CCSDS_CSTSWG (css-csts@mailman.ccsds.org)" <css-csts@mailman.ccsds.org></span>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#5F5F5F">Date: </span><span style="font-size:7.5pt;font-family:"Arial",sans-serif">04/03/2020 17:16</span>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#5F5F5F">Subject: </span><span style="font-size:7.5pt;font-family:"Arial",sans-serif">Re: [EXTERNAL] Re: [Css-csts] Forward Frame CSTS WG Review Package on CWE</span>
<o:p></o:p></p>
<div class="MsoNormal" align="center" style="margin-left:.5in;text-align:center">
<hr size="0" width="100%" noshade="" style="color:#A0A0A0" align="center">
</div>
<p class="MsoNormal" style="margin-left:.5in"><br>
<br>
<br>
<span style="font-size:12.0pt">Ho Holger,</span> <br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt">I like your analogy, but it immediately brings to mind, for me, the question "Why wouldn't it exactly be the case that
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif">this version of Word will work with any future version of Windows once available</span><span style="font-size:12.0pt">?" Striving hard to ensure backward compatibility ought to be a major
objective, even while we move into the future.</span> <br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt">When I look at Microsoft, and some of the choices that they have taken to drop backward compatibility in their products, I get really annoyed. I have been working long enough that I have written a lot of docs and presentations
that I still have on my computer. Some are "seminal" and are still relevant, some are merely historical and of value to me. But frequently, when I try to open these older (like even 10 years) Word and PPT files with the current crop of MS tools I get messages
that say "we do not have a clue what to do with this file". That is just sad and really annoying. </span>
<br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt">And note that it is not that the file is broken, but that the tool no longer supports this older format at all. Happily, in many cases, there are other tools like Open Office that do continue to support the older formats. So
I can open these files in Open Office, save them in a more recent format, and then go back into the new MS Office tools and open these "re-saved" files. It works, but it is awkward, painful, and must be done one by one.</span>
<br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt">All of that could be avoided. IMHO, we should, in our own work, attempt to do avoid these kinds of situations wherever we can. I realize that there are situations where we have to make changes to data structures and available
operations sets and features in order to move ahead. That is proper and that is what versioning is for. But please, let's try and not break older stuff when moving forward, and let's try and keep our existing standards up to date with the most current frameworks.</span>
<br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt">Thanks, Peter</span> <br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt"> </span> <br>
<b><span style="font-size:12.0pt">From: </span></b><span style="font-size:12.0pt">CSS-CSTS <css-csts-bounces@mailman.ccsds.org> on behalf of "Holger.Dreihahn@esa.int" <Holger.Dreihahn@esa.int><b><br>
Date: </b>Tuesday, March 3, 2020 at 11:33 PM<b><br>
To: </b>John Pietras <john.pietras@gst.com><b><br>
Cc: </b>CSS-CSTS <css-csts-bounces@mailman.ccsds.org>, CSTS-WG <css-csts@mailman.ccsds.org><b><br>
Subject: </b>[EXTERNAL] Re: [Css-csts] Forward Frame CSTS WG Review Package on CWE</span>
<br>
<span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">Dear John,</span><span style="font-size:12.0pt">
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><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...'.</span><span style="font-size:12.0pt">
<br>
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><br>
Best regards,</span><span style="font-size:12.0pt"> </span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><br>
Holger</span><span style="font-size:12.0pt"> <br>
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><br>
Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | S-431<br>
+49 6151 90 2233 | </span><a href="http://www.esa.int/esoc"><span style="font-size:12.0pt;font-family:"Arial",sans-serif">http://www.esa.int/esoc</span></a><span style="font-size:12.0pt">
<br>
<br>
<br>
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
From: </span><span style="font-size:12.0pt;font-family:"Arial",sans-serif">"John Pietras" <john.pietras@gst.com></span><span style="font-size:12.0pt">
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
To: </span><span style="font-size:12.0pt;font-family:"Arial",sans-serif">"CCSDS_CSTSWG (css-csts@mailman.ccsds.org)" <css-csts@mailman.ccsds.org>, "Wolfgang Hell" <wo_._he@t-online.de></span><span style="font-size:12.0pt">
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
Date: </span><span style="font-size:12.0pt;font-family:"Arial",sans-serif">03/03/2020 22:42</span><span style="font-size:12.0pt">
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
Subject: </span><span style="font-size:12.0pt;font-family:"Arial",sans-serif">[Css-csts] Forward Frame CSTS WG Review Package on CWE</span><span style="font-size:12.0pt">
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
Sent by: </span><span style="font-size:12.0pt;font-family:"Arial",sans-serif">"CSS-CSTS" <css-csts-bounces@mailman.ccsds.org></span><span style="font-size:12.0pt">
</span><o:p></o:p></p>
<div class="MsoNormal" align="center" style="margin-left:.5in;text-align:center">
<hr size="0" width="100%" noshade="" style="color:#A0A0A0" align="center">
</div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
<br>
<span style="font-size:12.0pt"><br>
<br>
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><br>
CSTSWG colleagues ---</span><span style="font-size:12.0pt"> </span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><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:</span><span style="font-size:12.0pt">
<u><span style="color:blue"><br>
</span></u></span><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"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#0082BF">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</span></a><span style="font-size:12.0pt">
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><br>
</span><span style="font-size:12.0pt"> </span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><br>
The zip file contains 3 files:</span><span style="font-size:12.0pt"> </span><br>
<span style="font-size:12.0pt">1. </span><span style="font-size:12.0pt;font-family:"Arial",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.</span><span style="font-size:12.0pt">
</span><br>
<span style="font-size:12.0pt">2. </span><span style="font-size:12.0pt;font-family:"Arial",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:</span><span style="font-size:12.0pt">
</span><br>
<span style="font-size:12.0pt">3. </span><span style="font-size:12.0pt;font-family:"Arial",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.</span><span style="font-size:12.0pt">
</span><br>
<span style="font-size:12.0pt">4. </span><span style="font-size:12.0pt;font-family:"Arial",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.</span><span style="font-size:12.0pt"> </span><br>
<span style="font-size:12.0pt">5. </span><span style="font-size:12.0pt;font-family:"Arial",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.“</span> <br>
<span style="font-size:12.0pt;font-family:"Arial",sans-serif"> </span><span style="font-size:12.0pt">
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><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>
</span><span style="font-size:12.0pt"> </span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><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.</span><span style="font-size:12.0pt">
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><br>
</span><span style="font-size:12.0pt"> </span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><br>
Thanks.</span><span style="font-size:12.0pt"> </span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><br>
</span><span style="font-size:12.0pt"> </span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><br>
Best regards,</span><span style="font-size:12.0pt"> </span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><br>
John</span><span style="font-size:12.0pt"> </span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><br>
</span><span style="font-size:12.0pt"> </span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><br>
EMAIL EXCHANGE BWTWEEN PETER SHAMES AND JOHN PIETRAS</span><span style="font-size:12.0pt">
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><br>
</span><span style="font-size:12.0pt"> </span><b><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><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?”
</span></b><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><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></span><span style="font-size:12.0pt">
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><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 “</span><span style="font-size:12.0pt">users
of this document are encouraged to investigate the possibility of applying the most recent editions of the publications indicated below”
</span><span style="font-size:12.0pt;font-family:"Arial",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.</span><span style="font-size:12.0pt">
</span><span style="font-size:12.0pt;font-family:"Courier New""><br>
</span><span style="font-size:12.0pt"> </span><b><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><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?</span></b><span style="font-size:12.0pt">
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><br>
</span><span style="font-size:12.0pt"> </span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><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: </span><span style="font-size:12.0pt">
</span><br>
<span style="font-size:12.0pt">1. 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.
</span><br>
<span style="font-size:12.0pt">2. 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.</span>
<br>
<span style="font-size:12.0pt;font-family:"Arial",sans-serif"> </span><span style="font-size:12.0pt">
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><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>
</span><span style="font-size:12.0pt"> </span> <br>
<span style="font-size:12.0pt">1. 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.
</span><br>
<span style="font-size:12.0pt;font-family:"Arial",sans-serif"> </span><span style="font-size:12.0pt">
</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><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.</span><span style="font-size:12.0pt">
</span><b><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><br>
</span></b><span style="font-size:12.0pt"> </span><b><span style="font-size:12.0pt;font-family:"Arial",sans-serif"><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.</span></b><span style="font-size:12.0pt;font-family:"Courier New"">_______________________________________________<br>
CSS-CSTS mailing list<br>
CSS-CSTS@mailman.ccsds.org</span><u><span style="font-size:12.0pt;color:blue"><br>
</span></u><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts"><span style="font-size:12.0pt;font-family:"Courier New"">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts</span></a><span style="font-size:12.0pt;font-family:"Courier New""><br>
</span><br>
<span style="font-size:12.0pt;font-family:"Courier New"">This message is intended only for the recipient(s) named above. It may contain proprietary information and/or</span>
<br>
<span style="font-size:12.0pt;font-family:"Courier New"">protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received</span>
<br>
<span style="font-size:12.0pt;font-family:"Courier New"">this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect</span>
<br>
<span style="font-size:12.0pt;font-family:"Courier New"">personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@esa.int).</span>
<o:p></o:p></p>
<pre style="margin-left:.5in">This message is intended only for the recipient(s) named above. It may contain proprietary information and/or<o:p></o:p></pre>
<pre style="margin-left:.5in">protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received<o:p></o:p></pre>
<pre style="margin-left:.5in">this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect<o:p></o:p></pre>
<pre style="margin-left:.5in">personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@esa.int).<o:p></o:p></pre>
</div>
</body>
</html>