[Css-csts] Re: Technical corrigendum for FCLTU and FSP

Ray, Timothy J. (GSFC-5830) timothy.j.ray at nasa.gov
Wed Dec 8 13:09:58 EST 2010


Hi Wolfgang,

For each of our SLE Blue Books, can we please post ASN.1 source code in plain-text format on the CCSDS web site?  

And, if there are any cases in which an existing SLE Provider uses ASN.1 that is not identical to the Blue Book (e.g. Forward-CLTU service?), can we please post the as-implemented version(s) of ASN.1 source code in plain-text format on the CCSDS web site?

If we do these things, then the planned upgrade of NASA's Near Earth Network will have a better chance of being compatible with the existing SLE implementations.

Thanks,
Tim

-----Original Message-----
From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of Wolfgang.Hell at esa.int
Sent: Wednesday, December 08, 2010 12:20 PM
To: John Pietras
Cc: css-csts at mailman.ccsds.org
Subject: [Css-csts] 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






_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts



More information about the Css-csts mailing list