[Css-csts] RE: [CSTS] Monitoring Data CSTS in the Concepts Green Book

[John Pietras]

Sorry - I forgot the attachment.

John

-----Original Message-----
From: John Pietras 
Sent: Thursday, May 14, 2009 3:17 PM
To: 'Martin Götzelmann'
Cc: css-csts at mailman.ccsds.org
Subject: RE: [CSTS] Monitoring Data CSTS in the Concepts Green Book

Martin,
Sorry to take so long to respond to you. I have been reacting to what we call a "fire drill".

In general the section looks just fine. I corrected a few typos and proposed some alternate wording in a few cases (see the attached file). Your new table entries seem to address the modifications that were raised, although they might be further revised as a result of any reconsideration we might have regarding the version number.

Your question about the version number raises some interesting issues that I don't recall discussing in our meetings. Having thought about it over the past day or so, I don't have any easy conclusions. 

To start, I think that if the procedure is derived in that specification (or created from individual operations) then the version number of the procedure is taken from that specification. If the procedure is directly adopted from the Framework or another service, then the version number is the version number of the procedure in the source. 

I'll use your hypothetical abstract Return Space Link Data (RSLD) CSTS as an example. In the RSLD CSTS specification, the Association Control procedure is directly adopted from the CSTSFW Association Control procedure, and the Delivery, Status Report, and Configuration Query procedures are derived from the CSTSFW Buffered Data Delivery, Cyclic Report, and Information Query procedures, respectively. For the sake of discussion, we'll assume that they are derived from the version-1 CSTSFW procedures. Note that in Colorado Springs we declared that any single service specification could not use procedures from multiple versions of the same source - all procedures from any given source have to all be taken from the same version of that source. 

Using my rule of thumb from above, for the version-1 of the RSLD-CSTS specification, the (adopted) Association Control procedure is version 1 because it's the CSTSFW version-1 version of that procedure. The Delivery, Status Report, and Configuration Query procedures are version 1 because they are defined in the version-1 RSLD service spec. The Version row entry adds no information, since the version of a directly-adopted procedure is taken from the source, and the version of the derived procedures is taken from the specification itself (in which those derivations are defined). The version of the source (CSTSFW) procedures for the derived procedures is obtainable from the version of the Reference for that source (i.e. version-1 in this example).

The question gets a bit more complicated regarding derived procedures in later versions of a service specification. Let's now assume that we have a version 2 of the RSLD CSTS, in which the Status Report procedures is slightly modified, but the Delivery and Configuration Query procedures are unchanged from the version 1 RSLD specification. Should the version-2 RSLD service spec respecify these unchanged procedures, or should they simply be inherited from version 1? 

If we take the first approach (in which all derived procedures are redefined in each version of the specification), then the version of the RSLD: Delivery procedure would be "2" (since it's being redefined in the Version-2 specification), the Specification Approach would be "derived", and the Source would be "CSTSFW: Buffered data Delivery". Furthermore, the version 2 FSLD spec would repeat the definition of the derived procedure. In this approach, the version number of the derived procedures is always equal to the version number of the specification in which that procedure appears. In other words, the Version row of the table provides no unique information.

However, if we take the second approach (allowing the version 2 procedure to be inherited from the version 1 spec), then the RSLD: Delivery procedure could be identified as version 1, the Specification Approach would be "adopted", and the Source would be "RSLD: Delivery", with the version number used to identify that is was a previous version of the RSLD service that defined the procedure. The version 2 FSLD spec would not repeat the definition of the RSLD: Delivery procedure because it is directly adopted from the version 1 spec. In this case, the Version row of the table *does* provide information that can't be derived from the specification itself - namely, in which previous version of the current specification the procedure definition can be found.

Of these two approaches, I like the second because it allows later versions to simply adopt by reference procedures from earlier versions. The one downside that I can see is that as long as any version references an earlier version, that earlier version can't be deprecated. If that is an issue, one way around it would be to still define each derived procedure in each version even if the procedure hasn't changed, but to retain the procedure version number from the version in which that procedure was originally defined. That way, even though the specification is complete (i.e., no earlier versions have to remain active just for the purpose of having its procedures referenced), the version number would indicate that the definition hasn't changed. This would be especially useful for software re-use: if I have a version-1 RSLD: Delivery module, I know that I can just re-use it in my version-2 implementation. It does bring up a secondary issue - if, say versions 1 -4 all use the same version (1) of the RSLD: Delivery procedure, and the RSLD: Delivery procedure gets modified in version 5 of the RSLD spec, does the modified procedure get a version number of "2" or "5"? I would opt for 5, keeping the linkage with the spec version in which it is defined over single-digit incrementing.

I haven't given you a simple answer (I never do). But I hope that we in the CSTSWG can come to some common understanding of what the Version row signifies. I may be completely out of sync with the rest of the WG in my thinking, but these are my thoughts and preferences.

Best regards,
John


-----Original Message-----
From: Martin Götzelmann [mailto:martin.goetzelmann at vega.de] 
Sent: Tuesday, May 12, 2009 4:40 PM
To: John Pietras
Cc: css-csts at mailman.ccsds.org
Subject: [CSTS] Monitoring Data CSTS in the Concepts Green Book

Dear John,

I am trying to complete the concepts book before I go on leave end of this week. Annex C includes an outline of examples and the first one is the Monitoring Data CSTS. I have tried to come up with a description based on issue 0.7 and my notes / recollection of the discussions in Colorado Springs. I have also changed the "composition table" according to my perception of the conclusions because I needed something to describe. This is not meant to anticipate the final specificatin - I believe it will be easy to adapt it to the final version that will be specified by the Guidelines.

The purpose of the outline is of course not primarily to describe the MD CSTS but to describe an example of how the Framework is used.

I would be grateful if you could look at this (only 2.25 pages) and let me know if you find any major issues with this outline. Details can be fixed in the (hopefully) final version following the next review round.

In this context I have one question concerning the row "Version" in the composition table. Does this row refer to specification in the service specification or to the source. If the source is adopted there may be no difference, but different versions might apply if a new procedure is derived from the source. Do we need to specify two versions in the table?

Kind Regards,

Martin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: MDCSTS-jvpComments.doc
Type: application/msword
Size: 114176 bytes
Desc: MDCSTS-jvpComments.doc
Url : http://mailman.ccsds.org/pipermail/css-csts/attachments/20090514/5ea22e20/MDCSTS-jvpComments-0001.doc