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

Fri May 15 04:52:08 EDT 2009

Dear Yves,

Reading John's mail and looking at the specification framework raises yet
another question for me : shouldn't we specify for the derived procedures
(i.e. the cyclic report at the moment) the version number used of the base
procedure ?
Indeed we specify the version number of the procedure itself (§4.7.2.1.1 :
"The version number of this procedure is 1.") we state that the base
procedure is the unbuffered data delivery and that the source operations are
took from there (See table 4-21 in §4.7.3) but we never link to the version
of this base procedure.
Isn't it missing ?

Best regards,
Cyril.

-----Message d'origine-----
De : css-csts-bounces at mailman.ccsds.org
[mailto:css-csts-bounces at mailman.ccsds.org]De la part de John Pietras
Envoyé : jeudi 14 mai 2009 21:17
À : Martin Götzelmann
Cc : css-csts at mailman.ccsds.org
Objet : [Css-csts] RE: [CSTS] Monitoring Data CSTS in the Concepts
GreenBook

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

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