[Css-csts] Re: MD-CSTS "RIDs" resulting from Guidelines comparison - part 1

[Yves.Doat at esa.int]

Dear John,

It took me long to find time for your mail and I am sorry for that.

Please fond below my answers in blue.

1.       Wolfgang pointed out that the structure and content of section 
3.1 of the MD-CSTS does not match that prescribed in the Guidelines. As I 
explained to Wolfgang, that is because the WG decided to write the MD-CSTS 
and TD-CSTS books so that it would not be necessary to consult the 
Guidelines in order to understand them. As defined in the Guidelines, the 
content and structure of section 3.1 is very terse and table-oriented, and 
it requires the reader to have the Guidelines available in order to 
understand the table. What I did in section 3.1 of the MD-CSTS (and 
TD-CSTS, too) was to basically supply the words that explained the 
contents of the table in lieu of the Guidelines being available. The 
deviation from the Guidelines found in the MD-CSTS and TD-CSTS will be 
used in CSTS specifications only until the Guidelines is published. Any 
CSTS specification written after that will use the terse, table-oriented 
content defined by the Guidelines.
I did not change the text of section 3.1 of the Guidelines.

2.       Section 4.7 of the Guidelines calls for a section called ?Managed 
Information?
Following the teleconference (29.01.2015) and as agreed I changed the name 
of section 4.7 to  ?Setting of Configuration Parameters Inherited from 
Framework Procedures?.As proposed by John,  I changed the paragraph under 
7.1, General. To read: 
?The procedures of the CSTS SFW define configuration parameters for the 
Framework procedures, but defers to the derived services the specification 
of the method by which each of those configuration parameters is to be 
set. This section specifies the method by which each of the Framework 
procedure configuration parameters is to be set for the MD-CSTS.?

3.      Section 4.6.9:
I reworded it using your various cases you have listed.

Best regards

Yves
__________________________________________________
Head of the Ground Facilities Infrastructure Section  (HSO-ONI) 
in the Ground Facilities Operations Division
ESA/ESOC Robert-Bosch Strasse 5
D-64293 Darmstadt, Germany
Tel.: +49 (6151) 90.2288               Fax:+49 (6151) 90.3046
Internet: http://www.esa.int/
__________________________________________________




From:   John Pietras <john.pietras at gst.com>
To:     "Yves.Doat at esa.int" <Yves.Doat at esa.int>
Cc:     "Wolfgang_._Hell at t-online.de" <Wolfgang_._Hell at t-online.de>, 
"CCSDS_CSTSWG (css-csts at mailman.ccsds.org)" <css-csts at mailman.ccsds.org>
Date:   19/11/2014 22:54
Subject:        MD-CSTS "RIDs" resulting from Guidelines comparison - part 
1



Dear Yves,
I was sorry that you were not able to attend the meeting in London last 
week. As Wolfgang may have already told you, on Tuesday he and I discussed 
some questions and RIDs that resulted from your analysis of the MD-CSTS 
vis-à-vis the Guidelines. When I started this email I had intended to 
address all of the issues, but my response to the second got rather long 
and complicated and resulted in a ?review? of part of the Guidelines 
document itself. So rather than addressing all of the ?RIDs? in this 
email, I have addressed only the first two. I?ll let you start thinking 
about these responses and I?ll complete ?part 2? in the near future.
 
1.       Wolfgang pointed out that the structure and content of section 
3.1 of the MD-CSTS does not match that prescribed in the Guidelines. As I 
explained to Wolfgang, that is because the WG decided to write the MD-CSTS 
and TD-CSTS books so that it would not be necessary to consult the 
Guidelines in order to understand them. As defined in the Guidelines, the 
content and structure of section 3.1 is very terse and table-oriented, and 
it requires the reader to have the Guidelines available in order to 
understand the table. What I did in section 3.1 of the MD-CSTS (and 
TD-CSTS, too) was to basically supply the words that explained the 
contents of the table in lieu of the Guidelines being available. The 
deviation from the Guidelines found in the MD-CSTS and TD-CSTS will be 
used in CSTS specifications only until the Guidelines is published. Any 
CSTS specification written after that will use the terse, table-oriented 
content defined by the Guidelines.

2.       Section 4.7 of the Guidelines calls for a section called ?Managed 
Information?, whereas the corresponding section of the MD-CSTS book is 
called ?Configuration Parameters?. Your ?RID? states: ?The MD service uses 
the term ?CONFIGURATION PARAMETERS?, which is confusing with the 
?configuration parameters? subsection of the procedures.? 

Back when I originally wrote section 4.7 of the Guidelines several years 
ago, the CSTS SFW simply assumed that all of the configurable parameters 
of the Framework procedures would be set by management, and so section 4.7 
of the Guidelines was conceived to (a) identify the managed parameters 
that were inherited from the parent procedures, and (2) identify any new 
managed parameters that might result from the extension of those 
parameters. Over time, the CSTS SFW evolved to recognize that Framework 
procedure configuration parameters would not necessarily be ?managed? ? 
for some services, the values might be fixed by the services themselves. 
So instead of calling anything a managed parameter, they were all called 
configuration parameters, and a blanket statement was made in the FW that 
the definition of how each configuration parameter was to be set (by 
management, fixed value, etc.) was deferred to the specification of the 
service that used the procedures. Also, the now-called configuration 
parameters were moved from an annex in the back of the book to a 
designated section in each procedure specification.

When this change was made in the CSTS SFW, I modified the content of 
Section 7  of the MD-CSTS and TD-CSTS to address how the configuration 
parameters inherited from the FW are to be set for those services. In the 
case of the MD-CSTS, it happens to be that all of the configuration 
parameters are to be managed, but for the TD-CSTS the content of the 
default list is set by the TD-CSTS specification itself.

Even with these changes, the sections 7 continued to be called ?Managed 
Information?. I realized the inaccuracy of this title, and at the 
Noordwijkerhout meeting I proposed changing the name from ?Managed 
Information? to something that more accurately represented the purpose of 
the section ? to define how each of the configuration parameters inherited 
from the FW is to be set for the specific service. This change was 
approved in principle by the WG and I proceeded to change the name to 
?Configuration Parameters?.

If ?Configuration Parameters? as the title of section 7 is potentially 
confusing, we could give it a more-explicit title, something like ?Setting 
of Configuration Parameters Inherited from Framework Procedures?. I also 
propose to change the paragraph under 7.1, Genera. To read: 
?The procedures of the CSTS SFW define configuration parameters for the 
Framework procedures, but defers to the derived services the specification 
of the method by which each of those configuration parameters is to be 
set. This section specifies the method by which each of the Framework 
procedure configuration parameters is to be set for the MD-CSTS.? Finally, 
I would delete the NOTE under 7.2, as it is now redundant with the 
information in 7.1. 

If this proposal is acceptable, I will offer to provide some updated text 
for the Guidelines that address the current scope and content of this 
section. 

Related to this issue, I have looked at the new section 4.6.9 of the 
Guidelines that addresses the Configuration Parameters sections for 
refined, extended, or service-original procedures and I have a concern 
about the way it is currently constructed. The current wording states that 
if there are no additional configuration parameters, then the section 
should state that the inherited parameters are adopted without addition or 
modification. However, a concrete service specification *must* do more 
with the inherited configuration parameters ? specifically, it must define 
how those parameters are to be set (by management, etc.), and that is what 
is accomplished in the ?Setting of Configuration Parameters Inherited from 
Framework Procedures? section. As a consequence, I think that a 
Configuration Parameters section should only include new configuration 
parameters that are added by the derived or service-original procedures. 
Furthermore, if the derived/service-original procedure is for a concrete 
service (that is, one that can be implemented without addition 
specification), then how the configuration parameters are set must also be 
specified in the service specification. As a practical matter, if a new 
parameter is identified as a configuration parameter for a concrete 
service, it will in fact be a managed parameter because any fixed values 
will be defined elsewhere in the procedure. For example, if a 
specification fixes the number of instances of a procedure to the value N, 
that is no longer a configuration parameter because it cannot be 
subsequently adjusted. 

So far my examples have been with respect to concrete service 
specifications, but we also allow for the creation of abstract service 
specifications ? that is, specifications that require additional 
specification before they can be implemented. Abstract services *can* have 
configuration parameters that are unresolved, as long as the specification 
stipulates that they must be resolved in any derived concrete 
specification.

So to try to summarize my view on how to address these issues in the 
Guidelines, I?ll use the following use cases, which I believe address all 
the variations of concrete vs. abstract services using adopted vs. 
derived/service original procedures:

A)     If the derived service is concrete and the procedure is adopted: 
1)      There is no section describing the derived procedure, so there can 
be no Configuration Parameters section for that procedure.
2)      The ?Setting of Configuration Parameters Inherited from Framework 
Procedures? section must contain a section that addresses each of the 
configuration parameters of the adopted procedure and specifies how its 
value is set.

B)      If the derived service is concrete and the procedure is derived or 
service-original: 
1)      The section describing the derived/service-original procedure 
contains a Managed Parameters section for that procedure. 
a)      If the procedure adds no new managed parameters, the Managed 
Parameters section contains a simple statement to that effect. 
b)      If the procedure adds one or more new managed parameters, the 
Managed Parameters section a table similar to the Configuration Parameters 
table for the FW procedures.
2)      The ?Setting of Configuration Parameters Inherited from Framework 
Procedures? section must contain a section that addresses each of the 
configuration parameters of the adopted procedure and specifies how its 
value is set.

C)      If the derived service is abstract and the procedure is adopted: 
1)      There is no section describing the derived procedure, so there can 
be no Configuration Parameters section for that procedure.
2)      The ?Setting of Configuration Parameters Inherited from Framework 
Procedures? section must contain a section that addresses each of the 
configuration parameters of the adopted procedure. Because the service is 
abstract, the section may define how it is set (if it is known that all 
derived concrete service will use that method) of it may defer the method 
to the derived concrete services.

D)     If the derived service is abstract and the procedure is derived or 
service-original: 
1)      The section describing the derived/service-original procedure 
contains a Configuration and Managed Parameters section for that 
procedure. 
a)      If the procedure adds no new configuration or managed parameters, 
the Configuration and Managed Parameters section contains a simple 
statement to that effect. 
b)      If the procedure adds one or more new configuration parameters, 
the Configuration and Managed Parameters section a table similar to the 
Configuration Parameters table for the FW procedures that contains the new 
configuration parameters. By definition, any parameters that are declared 
to be configuration parameters in an abstract service specification have 
the method by which they are set deferred to derived concrete services.
c)       If the procedure adds one or more new managed parameters, the 
Configuration and Managed Parameters section a table similar to the 
Configuration Parameters table for the FW procedures that contains the new 
managed parameters. By definition, any parameters that are declared to be 
managed parameters in an abstract service specification are known and 
required to be managed for all derived concrete services.
3)      The ?Setting of Configuration Parameters Inherited from Framework 
Procedures? section must contain a section that addresses each of the 
configuration parameters of the adopted procedure. Because the service is 
abstract, the section may define how it is set (if it is known that all 
derived concrete service will use that method) of it may defer the method 
to the derived concrete services.
 
I look forward to your response (and the response of any WG member). If 
you are in some degree of agreement with what I am proposing, I can offer 
some specific wording for the Guidelines.
 
Best regards,
John 
 

This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20150201/1a03b507/attachment.html>