<font size=2 face="sans-serif">Dear John,</font>
<br>
<br><font size=2 face="sans-serif">It took me long to find time for your
mail and I am sorry for that.</font>
<br>
<br><font size=2 face="sans-serif">Please fond below my answers in blue.</font>
<br>
<br><font size=3 face="Calibri">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.</font>
<br><font size=2 color=blue face="sans-serif">I did not change the text
of section 3.1 of the Guidelines.</font>
<br>
<br><font size=3 face="Calibri">2. Section 4.7 of
the Guidelines calls for a section called “Managed Information”</font>
<br><font size=2 color=blue face="sans-serif">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: <br>
“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.”</font>
<br>
<br><font size=2 face="sans-serif">3. Section
4.6.9:</font>
<br><font size=2 color=blue face="sans-serif">I reworded it using your
various cases you have listed.</font>
<br>
<br><font size=2 face="sans-serif">Best regards</font>
<br>
<br><font size=2 face="sans-serif">Yves<br>
__________________________________________________<br>
Head of the Ground Facilities Infrastructure Section (HSO-ONI) <br>
in the Ground Facilities Operations Division<br>
ESA/ESOC Robert-Bosch Strasse 5<br>
D-64293 Darmstadt, Germany<br>
Tel.: +49 (6151) 90.2288
Fax:+49 (6151) 90.3046<br>
Internet: </font><a href=http://www.esa.int/><font size=2 face="sans-serif">http://www.esa.int/</font></a><font size=2 face="sans-serif"><br>
__________________________________________________<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">John Pietras <john.pietras@gst.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"Yves.Doat@esa.int"
<Yves.Doat@esa.int></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">"Wolfgang_._Hell@t-online.de"
<Wolfgang_._Hell@t-online.de>, "CCSDS_CSTSWG (css-csts@mailman.ccsds.org)"
<css-csts@mailman.ccsds.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">19/11/2014 22:54</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">MD-CSTS "RIDs"
resulting from Guidelines comparison - part 1</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3 face="Calibri">Dear Yves,</font>
<br><font size=3 face="Calibri">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.</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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.<br>
</font>
<br><font size=3 face="Calibri">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.” <br>
<br>
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.<br>
<br>
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.<br>
<br>
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”.<br>
<br>
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: <br>
“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. <br>
<br>
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.
<br>
<br>
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 *<b>must</b>* 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. <br>
<br>
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 *<b>can</b>* have configuration parameters
that are unresolved, as long as the specification stipulates that they
must be resolved in any derived concrete specification.<br>
<br>
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:<br>
</font>
<br><font size=3 face="Calibri">A) If the derived service
is concrete and the procedure is adopted: </font>
<br><font size=3 face="Calibri">1) There is no section
describing the derived procedure, so there can be no Configuration Parameters
section for that procedure.</font>
<br><font size=3 face="Calibri">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.<br>
</font>
<br><font size=3 face="Calibri">B) If the derived service
is concrete and the procedure is derived or service-original: </font>
<br><font size=3 face="Calibri">1) The section describing
the derived/service-original procedure contains a Managed Parameters section
for that procedure. </font>
<br><font size=3 face="Calibri">a) If the procedure
adds no new managed parameters, the Managed Parameters section contains
a simple statement to that effect. </font>
<br><font size=3 face="Calibri">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.</font>
<br><font size=3 face="Calibri">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.<br>
</font>
<br><font size=3 face="Calibri">C) If the derived service
is abstract and the procedure is adopted: </font>
<br><font size=3 face="Calibri">1) There is no section
describing the derived procedure, so there can be no Configuration Parameters
section for that procedure.</font>
<br><font size=3 face="Calibri">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.<br>
</font>
<br><font size=3 face="Calibri">D) If the derived service
is abstract and the procedure is derived or service-original: </font>
<br><font size=3 face="Calibri">1) The section describing
the derived/service-original procedure contains a Configuration and Managed
Parameters section for that procedure. </font>
<br><font size=3 face="Calibri">a) If the procedure
adds no new configuration or managed parameters, the Configuration and
Managed Parameters section contains a simple statement to that effect.
</font>
<br><font size=3 face="Calibri">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.</font>
<br><font size=3 face="Calibri">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.</font>
<br><font size=3 face="Calibri">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.</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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.</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">Best regards,</font>
<br><font size=3 face="Calibri">John </font>
<br><font size=3 face="Calibri"> </font>
<br><PRE>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.
</PRE>