[Css-csts] RE: Technical corrigendum for FCLTU and FSP
John Pietras
john.pietras at gst.com
Wed Dec 8 14:27:37 EST 2010
Wolfgang,
I did not realize that the changes had already been made in all of the
SLE books, and it wasn't clear to me that the changes would be handled
the same across all books. As long as all of the
CCSDS-SLE-TRANSFER-SERVICE-SERVICE-INSTANCE-ID module specifications are
identical, then my concerns will be answered once the TC is in place.
However, this case illustrates a concern of mine - namely, that the
silent correction provides no mechanism for letting the audience for a
document know when an update has been issued, short of downloading the
document itself and seeing the "ecX" in the filename and/or looking at
the Document Control page. I've suggested in the past that the
Secretariat establish some mechanism to allow people to somehow
subscribe to update notifications for individual books, but I was told
that the Secretariat doesn't have the resources to take on something
like that.
Tom - would it be possible to simply add a line at the end of the
description of each editorially-updated document to indicate that it has
undegone such a change? Something along the lines of "This Recommended
Standard includes the first set of editorial changes (EC1) with respect
to the original issue". The reader would still have to go to
www.ccsds.org to see if an update exists, but at least the change would
be evident from the web page itself and not require the reader to
download the document in order to know whether it's been updated.(BTW,
the name of the updated FCLTU file should contain "ec1" - it currently
does not.)
Best regards,
John
-----Original Message-----
From: Wolfgang.Hell at esa.int [mailto:Wolfgang.Hell at esa.int]
Sent: Wednesday, December 08, 2010 12:20 PM
To: John Pietras
Cc: css-csts at mailman.ccsds.org; Margherita.di.Giulio at esa.int
Subject: Re: Technical corrigendum for FCLTU and FSP
John,
Firstly, I completely agree with you that in retrospect it would have
been
better to have a separate ASN.1 repository from which the service
specifications import what they need. But at this point the effort for
introducing such modification can hardly be justified and we will have
to
live with what we have got except that we shall take into account this
lesson
learned for the CSTS specifications.
I understand your concern regarding RAF, RCF and ROCF, but as you point
out
yourself there is a fundamental difference with respect to F-CLTU and
FSP.
Even if somebody had taken the incorrect ASN.1 module and implemented
the
return services accordingly, everything would have been correct as all
errors
in the ASN.1 module affected the forward services only. Therefore in my
mind
for these three books a 'silent' correction (purely editorial error) is
justified and in fact if you go to the CCSDS WEB site and retrieve any
of the
return services, you'll find that now the ASN.1 module is correct. Tom
already did the update.
For F-CLTU and FSP, the situation is different as an implementation
according
to the book would not have been interoperable with any of the existing
implementations. Although also here Tom did the silent correction, we
should
make the change truly evident by retroactively introducing the change by
means of a Technical Corrigendum. But the net result of all what has
happened
is that the module in question is today the same in all service
specifications and as a consequence we won't have a problem with SANA.
Best regards,
Wolfgang
From: "John Pietras" <john.pietras at gst.com>
To: <Margherita.di.Giulio at esa.int>, <wolfgang.hell at esa.int>
Cc: <css-csts at mailman.ccsds.org>
Date: 01/12/2010 17:03
Subject: Technical corrigendum for FCLTU and FSP
Margherita and Wolfgang,
The AOB section (15) and Other Projects table (section 16.2) in the
London MoM states that a technical corrigendum will be developed for
each of the FCLTU and FSP specifications to correct the error regarding
Service Instance Identifier syntax in the ASN.1. However, although this
error is in the specification of the FCLTU and FSP Service Instance
Identifiers and therefore only technically affects these two service,
the error in fact appears in all five existing SLE service
specifications, because all five share the common
CCSDS-SLE-TRANSFER-SERVICE-SERVICE-INSTANCE-ID module that addresses all
SLE services called out in the Cross Support Reference Model, Part 1
(even services that have not yet had service specifications written for
them and may not ever have them). Correcting it only for FCLTU and FSP
would essentially mean that there are two different versions of the same
module, which might cause problems if, for example, SANA stores only one
"copy" of the module (although I must admit that I don't know how SANA
plans to handle these).
Is the plan to produce a technical corrigendum that covers both the
FCLTU and FSP books? If so, the simple solution would be to also include
RAF, RCF, and ROCF also in the purview of the technical corrigendum. If
each book must get its own corrigendum, then it becomes a bit more
document-intensive to correct the return SLE books.
In retrospect, it probably would have been better to establish a single
specification for the CCSDS-SLE-TRANSFER-SERVICE-COMMON-TYPES,
CCSDS-SLE-TRANSFER-SERVICE-BIND-TYPES, and
CCSDS-SLE-TRANSFER-SERVICE-SERVICE-INSTANCE-ID modules and have the
individual service specification import from the common specifications
(essentially a mini-framework, but only in terms of the ASN.1). Then any
repairs common to all services could be fixed in one place.
Perhaps the CSTSWG discussed these various aspects when coming to the
conclusion to produce technical corrigendum(s?) for FCLTU and FSP, and
if so I apologize for bringing the issue up again. But in any case I
don't think that it is right to leave the errored definitions in the
RAF, RCF, and ROCF books.
Best regards,
John
-----Original Message-----
From: Margherita.di.Giulio at esa.int [mailto:Margherita.di.Giulio at esa.int]
Sent: Tuesday, November 09, 2010 10:19 AM
To: martin.goetzelmann at vega.de; yves.doat at esa.int;
francois.lassere at cnes.fr; John Pietras; Dorothea.Richter at dlr.de;
tim.ray at nasa.gov; wolfgang.hell at esa.int; Fred Brosi;
thomas.w.wickline at nasa.gov; Cyril.Thomas at c-s.fr; Sylvain.Gully at dlr.de
Cc: erik.j.barkley at jpl.nasa.gov
Subject: MoM from Fall Meeting in London.
Dear All,
I have uploaded the Minute of Meeting from the Fall Meeting at
http://cwe.ccsds.org/css/docs/CSS-CSTS/Meeting%20Materials/2010%20Fall/2
0101025%20MoM%20Fall%20Meeting_London_DRAFT.doc
Please let me know if you have any comment. Then I will finalise the
MoM.
For CNES (Francois): an action on CNES has been added to the action
register (A#14-1010F). Its scope had already been agreed in the text of
the
MoM, only the corresponding action was missing.
For Erik: the decision about the monitor data parameters (Annex to MD
CSTS BB
versus Magenta Book) is not recorder in this MoM, as this has been
addressed
after the WG meeting (i.e. in the CESG meeting). This topic will be
addressed
in the next WG Teleconference and the outcome will then be recorded in
the
relevant MoM.
Kind regards,
Margherita
-----------------------------------------------------------
Margherita di Giulio
Head of Ground Station Back-end Section
European Space Agency ESA/ESOC
Robert-Bosch-Str. 5
D-64293 Darmstadt - Germany
Tel: +49-6151-902779
e-mail: Margherita.di.Giulio at esa.int
More information about the Css-csts
mailing list