[Css-csts] Follow-up on FF-CSTS discussion item regarding "strictness" of Guidelines

[John Pietras]

CSTSWG colleagues –
I believe that the consensus was that the Guidelines should be followed to the greatest degree possible in creating a new CSTS specification, but if that service has some special considerations that require going beyond the Guidelines that is okay, as long as that service specification identifies what the “beyond Guidelines” provisions are. In other words, we don’t have to update the Guidelines to add provisions for covering the new condition(s) in order to be able to write the service specification that exercises those provisions.

If this is indeed the consensus, then I propose some modifications to the Guidelines. I originally thought that we might be able to get away with a single disclaimer as the beginning of the Guidelines (e.g., in the Scope section), but on re-scanning the Guidelines I think that it would be helpful to spread such statements a few more places in the book. Here are my suggested changes (subject, of course, to further consideration and discussion). I’ve underlined the changed areas for emphasis, but of course am not suggesting that the underlines be included in the Guidelines.


1.       Section 1.2, Scope – change from

This Recommended Practice defines:

a)      the rules by which a new CCSDS-standard CSTS can be created from the CSTS procedures and operations defined in the CSTS Specification Framework Recommended Standard (reference[1]) or from existing concrete or abstract CSTSes;

NOTE   –    Figure 2-6 shows an example for the derivation of concrete CSTSes from an abstract CSTS.

b)      the technical information that is to be included in the specification of such a CSTS specification.

To

This Recommended Practice defines:

a)      the general rules by which a new CCSDS-standard CSTS can be created from the CSTS procedures and operations defined in the CSTS Specification Framework Recommended Standard (reference [1]) or from existing concrete or abstract CSTSes. These rules are to be followed to the greatest extent possible, with deviations only in the case of service-specific circumstances that cannot be accommodated by these general rules;

NOTE   –    Figure 2-6 shows an example for the derivation of concrete CSTSes from an abstract CSTS.

b)      the technical information that is to be included in the specification of such a CSTS specification.


2.       Section 1.5.1 (Document Organization), items (d) and (d) – change from

c)      section 3 documents the rules for definition of Cross Support Transfer Services;

d)     section 4 specifies the structure and content of a CSTS specification;

To

a)      section 3 documents the general rules for definition of Cross Support Transfer Services;

b)      section 4 specifies the nominal structure and content of a CSTS specification;


3.       Section 2, (Overview), in the second paragraph, change:

The second normative document for defining CSTSes, the Guidelines for the Specification of Cross Support Transfer Services (this Recommended Practice), defines (a) the requirements and constraints that govern the way in which a legal CSTS can be developed in accordance with reference [1]; and (b) guidance on the structure and content of real CSTS specifications.

To

The second normative document for defining CSTSes, the Guidelines for the Specification of Cross Support Transfer Services (this Recommended Practice), (a) defines the nominal requirements and constraints that govern the way in which a legal CSTS can be developed in accordance with reference [1]; and (b) provides guidance on the structure and content of real CSTS specifications.

NOTE –   The nominal requirements and constraints specified in the Guidelines are designed to address the needs of almost all potential CSTSes. However, there may occasionally be a CSTS that cannot perform its functions strictly within these requirements and  constraints. In such a case, the affected CSTS specification may deviate from the specific requirements/constraints that inhibit it from meeting the needs of the service, but such deviations must be the minimum required to meet the needs of that service..


4.       Section 3 (Rules for Definition of Cross Support Transfer Services) – insert the following requirement following the 3.0 heading but before the current 3.1 subheading:

To the greatest extent possible, each CSTS specification shall conform to the rules specified in this section. Exceptions are permitted only in special circumstances in which the rules cannot accommodate special needs of a specific CSTS. Deviations from these rules shall be the minimum possible in order to meet the needs of the CSTS, and must be documented as deviations from the Guidelines in the CSTS specification itself.


5.       Section 4 (Structure and Content of a CSTS Specification) – change

This section specifies the rules for the structure and content of a specification of a CSTS.
To

This section specifies the nominal rules for the structure and content of a specification of a CSTS. These structure and content rules correspond to services that are defined strictly within the context of the general rules specified in section 3. However, if deviations to any of those rules are necessary, such deviations may require corresponding changes in the structure and/or content of the CSTS specification. Any such changes in structure and/or content should be the minimum necessary to accommodate the needs of the specific service, and must be documented as deviations from the Guidelines in the CSTS specification itself.

Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20171010/92f436dc/attachment.html>