[Css-csts] [EXTERNAL] Re: Forward Frame CSTS WG Review Package on CWE

Thu Mar 5 07:20:06 UTC 2020

Ho Peter,
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.

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.

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...

Best regards,
Holger

Holger Dreihahn
European Spacecraft Operations Centre | European Space Agency | S-431
+49 6151 90 2233 | http://www.esa.int/esoc

From:   "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>
To:     "Holger.Dreihahn at esa.int" <Holger.Dreihahn at esa.int>, 
"EXTERNAL-Pietras, John V (US 332C-Affiliate)" <john.pietras at gst.com>
Cc:     "CSS-CSTS" <css-csts-bounces at mailman.ccsds.org>, "CCSDS_CSTSWG 
(css-csts at mailman.ccsds.org)" <css-csts at mailman.ccsds.org>
Date:   04/03/2020 17:16
Subject:        Re: [EXTERNAL] Re: [Css-csts] Forward Frame CSTS WG Review 
Package on CWE

Ho Holger,

I like your analogy, but it immediately brings to mind, for me, the 
question "Why wouldn't it exactly be the case that this version of Word 
will work with any future version of Windows once available?"  Striving 
hard to ensure backward compatibility ought to be a major objective, even 
while we move into the future.

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. 

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.

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.

Thanks, Peter

From: CSS-CSTS <css-csts-bounces at mailman.ccsds.org> on behalf of 
"Holger.Dreihahn at esa.int" <Holger.Dreihahn at esa.int>
Date: Tuesday, March 3, 2020 at 11:33 PM
To: John Pietras <john.pietras at gst.com>
Cc: CSS-CSTS <css-csts-bounces at mailman.ccsds.org>, CSTS-WG 
<css-csts at mailman.ccsds.org>
Subject: [EXTERNAL] Re: [Css-csts] Forward Frame CSTS WG Review Package on 
CWE

Dear John, 
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...'. 

Best regards, 
Holger 

Holger Dreihahn
European Spacecraft Operations Centre | European Space Agency | S-431
+49 6151 90 2233 | http://www.esa.int/esoc 

From:        "John Pietras" <john.pietras at gst.com> 
To:        "CCSDS_CSTSWG (css-csts at mailman.ccsds.org)" 
<css-csts at mailman.ccsds.org>, "Wolfgang Hell" <wo_._he at t-online.de> 
Date:        03/03/2020 22:42 
Subject:        [Css-csts] Forward Frame CSTS WG Review Package on CWE 
Sent by:        "CSS-CSTS" <css-csts-bounces at mailman.ccsds.org> 

CSTSWG colleagues --- 
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: 
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 

The zip file contains 3 files: 
1.       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. 
2.       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: 
3.       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. 
4.       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. 
5.       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.“

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. 

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. 

Thanks. 

Best regards, 
John 

EMAIL EXCHANGE BWTWEEN PETER SHAMES AND JOHN PIETRAS 

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?” 
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. 
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. 
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 *only* 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. 
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 “users of this document are encouraged to investigate the 
possibility of applying the most recent editions of the publications 
indicated below” 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. 

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? 

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:   
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. 
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.

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). 

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. 

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 *knows* 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. 

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.
_______________________________________________
CSS-CSTS mailing list
CSS-CSTS at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts

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 at esa.int).

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 at esa.int).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20200305/6eb8eab4/attachment-0001.htm>