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

Wed Nov 19 21:54:04 UTC 2014

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20141119/61bb705b/attachment.html>