[Css-csts] Forward Frame CSTS WG Review Package on CWE
Holger.Dreihahn at esa.int
Holger.Dreihahn at esa.int
Mon Mar 9 07:12:08 UTC 2020
Hi John,
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.
Let's discuss on Thursday.
Best regards,
Holger
From: "John Pietras" <john.pietras at gst.com>
To: "Holger.Dreihahn at esa.int" <Holger.Dreihahn at esa.int>
Cc: "CCSDS_CSTSWG (css-csts at mailman.ccsds.org)"
<css-csts at mailman.ccsds.org>, "CSS-CSTS"
<css-csts-bounces at mailman.ccsds.org>, "Wolfgang Hell"
<wo_._he at t-online.de>
Date: 04/03/2020 15:06
Subject: RE: [Css-csts] Forward Frame CSTS WG Review Package on CWE
Hi, Holger.
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.
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.)
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 *is* 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.
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.
I look forward to discussing this further next week.
Best regards,
John
From: Holger.Dreihahn at esa.int <Holger.Dreihahn at esa.int>
Sent: Wednesday, March 4, 2020 2:33 AM
To: John Pietras <john.pietras at gst.com>
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org)
<css-csts at mailman.ccsds.org>; CSS-CSTS
<css-csts-bounces at mailman.ccsds.org>; Wolfgang Hell <wo_._he at t-online.de>
Subject: 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:
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.
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:
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.
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.
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:
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.
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).
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/20200309/90a11590/attachment-0001.htm>
More information about the CSS-CSTS
mailing list