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

Tue Jul 10 10:46:37 EDT 2012

Martin,

Please disregard my confusing the version number used in the BIND invocation with the version numbers used  in the various ASN.1 modules (although I think with the latest Blue Book Issues these have all been brought into alignment). Regarding the use of the term "Issue" (in contrast to "version" ): "Issue" refers to the Blue Book - e.g., "B-2" is "Issue 2". We (or at least I) have been rather loose in the past with our terminology, referring to B-2 as "version 2". Often this does not cause a problem, but in the case of SLE, where "version" applies to the number in the BIND, it can be confusing. 

The important concern remains the same: should the API specifications continue to include the previous versions. To address your questions:

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?" As much as we all agree with the theory is that any new implementation should be based on the latest approved version/Issue of its controlling standard, that is not always the case. Long procurement cycles lock in Issues that change between the time the system requirements are written and the time the system is actually built. For whatever reason, there will be new implementations of Silver specifications. (This, I think, points to a fundamental flaw in our standards process - when we issue a new Blue Book, we (CCSDS) can "retire" the previous Issue of the book but our Agencies are not necessarily bound to move onto the latest Issues.) 

The point that I was trying to make in my original note was that if an error is discovered in an API book, the correction of that error should be formally documented even if the version/Issue of the corresponding Blue Book has been "retired". Of course, if the direction taken is to include all previous versions in the next Issues of the API books, any known errors in the previous Issue(s) can be corrected. But if the decision is to only address version 4 in the next Issue of the API book(s), corrections to errors in previous versions (specifically the version2 FCLTU API) will go unmade. Perhaps making such corrections are not CCSDS's responsibility: perhaps the CCSDS "warranty" only applies to the active version/Issue and  if anyone chooses to use a Silver version/Issue they are responsible for discovering/dealing with any hidden flaws (although it would seem a shame for CCSD to be aware of a problem and not make it known due to the lack of a formal mechanism to do so). 

2.       "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)."  This is the only error in any of the API books of which I am aware. 

Best regards,

John

From: Martin Götzelmann [mailto:martin.goetzelmann at vega.de] 
Sent: Tuesday, July 03, 2012 12:56 PM
To: John Pietras; css-csts at mailman.ccsds.org
Subject: RE: [Css-csts] Update of the SLE API Books - URGENT QUERY

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] On Behalf Of Martin Götzelmann
Sent: Tuesday, July 03, 2012 5:36 AM
To: 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

----------------------------------------------------------------

ORIGINAL MESSAGE

From: John Pietras 
Sent: Thursday, May 06, 2010 10:09 PM
To: Wolfgang.Hell at esa.int; Martinez, Lindolfo (lindolfo.martinez-1 at nasa.gov)
Cc: css-csts at mailman.ccsds.org
Subject: FW: CCSDS SLE FCLTU ERT/LRT discrepancy

Wolfgang and Martin,

Jonathan Brasier appears to have discovered a discrepancy between the FCLTU spec and the FCLTU API spec. My off-the-cuff assessment would be that the Blue Book (912.1) takes precedence over the Magenta Book (916.1). However, that does beg the question as to what the implementations that are based on the API do?

John

From: Brasier, Jonathan [mailto:jbrasier at rtlogic.com] 
Sent: Thursday, May 06, 2010 6:24 PM
To: John Pietras
Subject: CCSDS SLE FCLTU ERT/LRT discrepancy

John,

I'm the developer responsible for maintaining our SLE implementation here at RT Logic.

I was wondering if I could get a "ruling" from you on an inconsistency I've observed between two SLE FCLTU documents regarding the values of ERT and LRT within a CLTU-TRANSFER-DATA operation?  Or perhaps you would know to whom I should send this inquiry?

1.  According to CCSDS 912.1-B-2 paragraph 3.6.2.7.4, "If latest-radiation-time equals earliest-radiation-time, radiation shall occur at this time."  Which implies that ERT can be equal to LRT.

2.  However, 916.1-M-1 section A3.2 contains a table with the heading "Checking of Invocation Parameters" (pg. A-13 in the October 2008 version) which implies that ERT may not be equal to LRT:

"earliest radiation time: if earliest and latest radiation times are set, must be earlier than latest radiation time"

"latest radiation time: if earliest and latest radiation times are set, must be later than earliest radiation time"

3.  To complicate matters, 916.1-M-1 contradicts itself in paragraph 3.1.4.1.1.a where it implies that ERT can be equal to LRT:

"if the 'earliest radiation time' and the 'latest radiation time' are both specified, the

'earliest radiation time' must not be later than the 'latest radiation time'"

I was unable to find anything within these two documents which would indicate that one supersedes the other however, it's quite possible it's there and I overlooked it.

Which is correct?  ERT may equal LRT, or ERT may not equal LRT (i.e., ERT must always be earlier)?

Thank you,

Jonathan Brasier

RT Logic

-------------------------------------------------------

MOST RECENT RE-SEND

From: John Pietras 
Sent: Tuesday, September 13, 2011 10:51 AM
To: martin.goetzelmann at vega.de
Subject: RE: CCSDS SLE FCLTU ERT/LRT discrepancy

Resend of message ---

From: John Pietras 
Sent: Tuesday, June 28, 2011 4:24 PM
To: martin.goetzelmann at vega.de; wolfgang.hell at esa.int; 'Margherita.di.Giulio at esa.int'
Subject: FW: CCSDS SLE FCLTU ERT/LRT discrepancy

Martin, Wolfgang, and Margherita,

I came across this email today from a little more than a year ago. I don't remember if there was a final decision on what to do. Since Martin will be updating the API books to conform with the latest round of Blue Books, perhaps the fix for the problem below could be added, too.

Best regards,

John

From: Brasier, Jonathan [mailto:jbrasier at rtlogic.com] 
Sent: Friday, May 07, 2010 12:36 PM
To: John Pietras
Subject: RE: CCSDS SLE FCLTU ERT/LRT discrepancy

Thank you for the clarification and quick response John!

The Blue Book it is then.

Is there a document that summarizes the known discrepancies or is this the only one?

Also, is there a vehicle for receiving notifications when CCSDS specs have been updated/released?  For example, can I register for a notification whenever a SLE-related document is updated?

Lastly, a while back you had mentioned something about the SLE specifications possibly being broken out to a finer level of granularity.  I believe it was almost at the operation level?  I may have missed the mark here but if this rings a bell, has it gained any traction?

Thanks again for the clarification!

Jonathan 

From: John Pietras [mailto:john.pietras at gst.com] 
Sent: Friday, May 07, 2010 8:25 AM
To: Brasier, Jonathan
Subject: RE: CCSDS SLE FCLTU ERT/LRT discrepancy

Jonathan,

Go with the Blue Book, which is the "Standard". The API spec is wrong in this respect. I've brought this up with the WG, and they agree with that assessment. They are now discussing wahat to do about fixing the API books (or at least somehow exposing the error).

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20120710/5d1b66fd/attachment-0001.html