[Css-csts] Update of the SLE API Books - URGENT QUERY

Tue Jul 3 12:55:40 EDT 2012

Dear John,

I am not sure that I understand the difference between issue and version as you describe them. What I meant by version is the version number that is inserted in the BIND Invocation. For an API supporting more than one version of a service this is the important number as it selects the specific version applicable to a service instance.

A more precise definition is given in Applicability section of each of the API Books. According to that

·         Version 1 for CLTU, RAF, and RCF refers to the red books on which the very first implementation was based

·         Version 2 for CLTU, RAF, and RCF  refers to B-2

At the time this specification was released there was only one version of ROCF and FSP, namely version 1 referring to B-1.

The current API specification is written such that an implementation that fully implements it can support version 1 and version 2 for CLTU, RAF, and RCF. I believe that the intention had really been to allow support of multiple versions by an implementation. You can see this e.g. from annex A.3.1 of the CLTU API specifying the interface to the START operation. This interface specifically includes a method that are applicable to version 1 only (CLTU_Id Get_FirstCltuId) and a special method (Get_FirstCltuIdUsed) to check whether that method is applicable.

If we continue that approach we would now have to say that the API specifications supports

·         Version 1, 2, and 4 for CLTU, RAF, and RCF; and

·         Version 1 and 4 for ROCF and FSP.

Assuming that API implementations conform to the current specification, this would be the smallest change but I am not sure whether that is really in line with the general CCSDS approach.  However, dropping the history and only supporting version 4 of the SLE services would mean that an API implementation wanting to support previous versions would either have to duplicate interfaces or extend interfaces in a manner not defined in the specification. Another question is of course how long older versions shall be supported - if we continue the approach of supporting multiple SLE versions, do we still want to support version 1?

I do not fully understand your argument that we can only drop the past if the current magenta books are fully correct. Why should we bother about correcting retired specifications?

What concerns me is that I had missed the correction that you correctly point out to be required for  A3.2 of 916.1-M-1. I am sure you told me but I have obviously not recorded that. Do you have a record of any other changes that are required? If so, could you please let me have them (again).

So far,  I had simply looked into the differences between the most recent blue books (version 4) and the earlier blue books to identify the required changes. I have recorded those changes in a document called "SLE V4 Changes.docx" and uploaded it to the CWE (Cross Support Services Area (CSS) > Documents > CSS-CSTS > CWE Private > SLE API) - in case you would like to cross-check.

Kind Regards, Martin

From: John Pietras [mailto:john.pietras at gst.com]
Sent: 03 July 2012 16:41
To: Martin Götzelmann; css-csts at mailman.ccsds.org
Subject: RE: [Css-csts] Update of the SLE API Books - URGENT QUERY

Martin,
Just to be clear, when you say that that the current books "support version 1 and version 2", I believe that means that they support Issue-1 RCF, ROCF, and FSP and Issue-2 F-CLTU and RAF. "Version 4" as used below refers to the version numbers that appear in the ASN.1 modules, replacing the mix of "version-one" and "version-two" module version numbers. "version 4" modules appear in the current issues of the SLE suite - Issue 3 F-CLTU and RAF, and Issue 2 RCF, ROCF, and FSP.

Theoretically, one would need only to support "version 4" in the new issue of the API books because the Historical (Sliver) versions of the first issues) would logically apply to their associated Blue Books. However, that only works if the previous Magenta books do indeed accurately reflect their respective Blue Books.  Unfortunately, there is at least one instance where this is not the case -FCLTU B-2 allows earliest radiation time to equal latest radiation, but the Checking of Invocation Parameters table in section A3.2 of 916.1-M-1 implies that ERT may not be equal to LRT (we have discussed this in emails over the past few years). The decision has been made clear - the Blue Book is correct (they can be equal). However, this decision has not made its way into the erred table of the API book.

It is my understanding that there will still be some new implementations of Issue-2 F-CLTU, and if those implementations use the API then the relevant  API specifications should be correct. At the very least, there should be some official correction, even if it does not involve a re-issue of the book itself.

It would be a shame to have to cover the previous versions in the new API books if the only reason for doing so is to correct one or two errors. Would it make sense to issue a technical corrigendum against the current version and then essentially immediately transition it and the current API books to Silver status so that the correction is documented without having to correct it in the new API Magenta Book issues? I'm copying Tom Gannett on this message to ask if he has any recommendations for handling this problem with minimum effort.

In the meantime, I'm going to try to see if the potential NASA implementer of Issue-2 F-CLTU still plans to do so, and if they are still planning to use the API.

Best regards,
John

From: css-csts-bounces at mailman.ccsds.org<mailto:css-csts-bounces at mailman.ccsds.org> [mailto:css-csts-bounces at mailman.ccsds.org]<mailto:[mailto:css-csts-bounces at mailman.ccsds.org]> On Behalf Of Martin Götzelmann
Sent: Tuesday, July 03, 2012 5:36 AM
To: css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>
Subject: [Css-csts] Update of the SLE API Books - URGENT QUERY

Members of the CSTS Group,

I have finally started with the update of the SLE API Books and of course immediately come across an issue that I cannot decide on my own. The current books support version 1 and Version 2  of the RAF, RCF, and CLTU specifications.  The purpose was to allow implementations that support old versions as well.

Shall this approach be maintained and simply support for Version 4 (this is really the current version - version 3 has been skipped for a number of reasons) added or shall support for old versions be removed?

Thanks for a quick response,
Martin

_______________________
Martin Götzelmann
Principal Consultant Technology

VEGA Space GmbH
Europaplatz 5
64293 Darmstadt
Germany
Tel        : +49 (0)6151 8257-147
Fax       : +49 (0)6151 8257-799
Email   : martin.goetzelmann at vega.de<mailto:martin.goetzelmann at vega.de>
Web     : www.vega.de

Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231
Managing Directors/Geschäftsführer: Sigmar Keller, John Lewis

Notice of Confidentiality
This transmission is intended for the named addressee only. It contains information which may be confidential and which may also be privileged.  Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else.  If you have received this transmission in error please notify the sender immediately.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20120703/2120a0ed/attachment.html