[Css-csts] Directive Procedure Document: Rev1

Tue May 30 04:28:16 EDT 2006

Dear Charles,

Looking at your procedure we have the following comments.

A. Throw-Event procedure making use of the CONTROL-DIRECTIVE operation:
   The title of your procedure is CONTROL-DIRECTIVE.
   The working group agreed to name the procedure Throw-Event procedure (See
   Minutes of meeting of our February meeting). The Throw-Event procedure
   would make use of the DIRECTIVE operation.
   The name and the text should be changed accordingly.

   Section 1.1, 1st paragraph
   "The purpose of the procedure is to map the THROW-EVENT, INVOKE-DIRECTIVE,
   TRANSFER-DATA, SET and GET parameters into a generic directive that is
   common to all SLE services".
   This sentence is quite confusing as it gives the impression that the
   CONTROL-DIRECTIVE operation replaces THROW-EVENT, INVOKE-DIRECTIVE,
   TRANSFER-DATA, GET and SET.
   I am also confused about what you call the procedure, a directive and an
   operation.
   During our February meeting we stated: "The Throw-Event procedure would
   make use of the Control-Directive operation" (Section 2.7 of the Minutes
   of Meeting). As such the CONTROL-DIRECTIVE cannot be an operation that
   replaces all other operations. The procedure should be updated to reflect
   what the procedure covers and what operations are needed.
   It is also not clear to us why you prefix the procedure with the term
   "GENERIC". As all agreed procedures are at the same level there is no need
   to prefix them with GENERIC.

   Section 1.1 Properties of the procedure.: "Enables extensibility for
   Directive directive operations of all existing and future new SLE data
   transfer services".
   We have agreed for a number of procedures and this sentence gives the
   impression that your propose procedure covers everything (including data
   transfer). We have identified a set of procedures each of them covering an
   identify behaviour. This procedure is not supposed to cover all possible
   behaviour. I assume that I misunderstood the text. Could you update it.

   Section 1.1.2 Table
   The table in that section should be moved to a section describing the
   operations or I assume this table will disappear in the future.
   I assume this table is a mapping showing that you can cover all those
   operations with the agreed set of operations. If that's correct, then this
   table should not be copied to the future toolkit document. This table
   should either be removed or alternatively copied to an annex that will not
   be part of the ultimate Recommendation.

   Section 1.1.2. Table
   The list of operations seems to cover much more than the Throw-Event
   procedure. My understanding is that GET and TRANSFER-DATA do not belong to
   that procedure.

   Section 1.2.1.
   Where is the Throw-Event procedure defined? I thought it was that one.

   Section 1.2.2.1 Why are you describing GET and SET parameters in the
   concept section? I assume this text will disappear.

B. Other comments:
   Section 1.1 "Promotes reusability, modularity and improves operational
   efficiency"
   That's the purpose of the toolkit and not only of this procedure. This
   text should go into the main document (to be written).

   Section 1.1.2 Example.
   In example 2 the control directive is used to specify the type of report
   that shall be submitted but it is not clear to me how and when the report
   is actually transferred.

   Section 1.3.1 - PEER-ABORT invocation
   The peer-abort invocation belongs to the association procedure and should
   be removed from the text.

   Section 1.3.1 A lot of checks are performed but the definition lacks
   detailed information on how those check are performed.
   As an example, it is not clear how you identify if a directive-type is to
   be sent to Management? How do you achieve this check?

   Section 1.3.1. The text addresses the invocation of the operation and then
   what happen on the provider side. I would expect a description of what the
   user is supposed to provide as request parameters. The provider behaviour
   does not belong to that section.

   Section 1.3.2 If the directive is not successfully executed a negative
   response is sent back. Can you provide a list of possible reasons? Do we
   have to assume that the reasons can only be defined by the application
   executing the DIRECTIVE? I assume that some general reason can be foreseen
   (e.g. 'resource not available', ...).

   Section 1.3.3 Complex Management interface
   Directive-Type and identifier
   From the text I have the feeling that Directive-Type and Directive ID are
   known by user, provider and complex management.
   Could you please explain how is this list known? How would it be kept
   consistent?

   Section 1.8.1: GET and TRANSFER-DATA are not part of this procedure.

   Section 1.8.2.1. 'operation not supported'
   On one hand I consider that if a service selects that procedure, this
   operation must be supported.
   On the other hand in case this error would happen, the provider could not
   decode the operation and would report a decoding error.

   Section 1.8.2.2. Directive-Type:
   The description should identify if we can have an exhaustive list of types
   or if we have to foresee an extension capability.

   Section 1.8.2.3. Directive-Identifier:
   Is the directive identifier a concatenation of the directive-type and a
   directive instance identifier?

   Section 1.8.2.9 Extension-Parameter.
   The extension parameter ensures a new service to add whatever information
   it needs. Is that what is meant by your text? (this is not what I
   understand).

   Issue: The procedure describes the behaviour up to the handling of the
   request by the Complex Management. Do we want the Toolkit to describe this
   behaviour which is outside the scope of the Toolkit?

Best regards

Yves DOAT
__________________________________________________
Head Ground Infrastructure Baseband Section (OPS-GIB)
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/
__________________________________________________

             Charles J Ruggier                                               
             <Charles.J.Ruggier                                              
             @jpl.nasa.gov>                                               To 
             Sent by:                   css-csts at mailman.ccsds.org           
             css-csts-bounces at m                                           cc 
             ailman.ccsds.org                                                
                                                                     Subject 
                                        [Css-csts] Directive Procedure       
             07/04/2006 22:55           Document: Rev1                       

Dear CSTS WG Members:

I have uploaded a revised version of the "SLE Generic Control Directive
Procedure Specification."   This document is being submitted for your
review in response to Action Item 15-0206 and can be found at the CCSDS/CWE
CSS-CSTS web site:
<http://public.ccsds.org/sites/cwe/csts/default.aspx>, under  Documents -
SLE Toolkit Procedures folder - SLE Generic Control_Directive_2rev1

The document has been revised to reflect the new procedures and in response
to review comments from the CSTS Interim meetings held at ESOC in
February/06.  Other changes have been included for consideration in an
effort to improve the harmonization and overall efficiency of the
procedure.  The major changes to the document are summarized below:

(1)  The document text and UML models have been modified per new procedures
as outlined at the Atlanta and ESOC Interim meetings.

(2) The Control-Directive procedure assumes 3-phase confirmation of the
processed and executed directive: invoked request, acknowledged return, and
final confirmed return.

(3)  Transfer-Data, Set and Get parameters are included as parameters
associated with the Control-Directive operation.  The underlying principle
here assumes that the Control-Directive is a generic operation that
controls service production parameters (except commanding) and the
retrieval of requested data.  Transfer-Data, Set and Get are considered
here to be directive-mapped parameters and not stand-alone operations.

Best Regards,

Charles Ruggier

Jet Propulsion Laboratory
Telephone: +1 818-354-1823
Fax: +1 818-393-3505

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