[Css-csts] Re: Updated CSTS SFW on CWE - labels

Mon Jun 24 10:42:08 EDT 2013

Dear John,

I had a look in your proposed changes and find them very valuables. I could
classify them into three topics:
   Editorial: No additional questions
   Operations Return: You have pointed out some inconsistencies and proposed
   some changes. I have to check the return for each operation making sure
   that labels/names are properly addressed (in particular in case of error).
   Label/Name: It is not clear to me if you are in favour of having an
   operation mixing labels and names. E.g. a user could request some
   parameters with names and others with label using the same operations.
   While I see the reason I am somehow concerned on the complexity
   implication and therefore not convinced by such an approach. Could you
   please clarify your proposed approach mixed labels/names or not-mixed
   labels/names

Thinking about the label use, I was wondering what the provider should return
in case requesting labels and the provider has several names for that label.
Should he return all available names (i.e. one per FR instance)?

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:         "CCSDS_CSTSWG (css-csts at mailman.ccsds.org)" <css-csts at mailman.ccsds.org>                                             

  Date:       19/06/2013 21:36                                                                                                     

  Subject:    Updated CSTS SFW on CWE - labels                                                                                     

Yves,
As we discussed in the CSTSWG telecon earlier today, I have identified an
number of places where the additional capability to use parameter and event
labels needs to be documented. I have marked-up a copy of the SFW draft and
uploaded it to the CWE at URL
http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/CSTS%20Framework%20and%20Concept/921x1r2%5BDraft%20201306%5D%20-%20Return%20Services-JVP.docx

In addition to enabling Word markup for additions and deletions, I have also
flagged each of my changes with a comment balloon to differentiate my
proposed changes from the others that were already in the document.

Following is a summary of the changes that I made. I also found a few typos,
which I corrected.

1.       3.11.2.2.2.1, GET list-of-parameters: In some places the
list-of-parameters is specified as containing a list of individual parameter
names or labels, but here it is specified as containing a list of individual
parameter names or a list of individual parameter labels. The difference is
significant: in the first case, the list-of-parameters can contain a mix of
names and labels, whereas in the second case it is restricted to contain all
names or all labels. I recommend that the more-general mix be supported,
which would require that 3.11.2.2.2.1 be reworded. I marked the section with
a comment but I did not make the change myself.
2.       3.11.2.3.1(b), GET diagnostic: extends ‘unknown parameter
identifier’ to also cover parameter identifiers carried in Parameter Labels.
3.       4.4.2.2, Information Query Concepts: addresses querying using
individual parameter labels.
4.       4.7.2.2, Cyclic Report Concepts: completes the uses of parameter
labels.
5.       4.7.3.1.3, Cyclic Report Starting Behavior: adds support for
parameter labels.
6.       4.7.4.1.2.4, Cyclic Report START list-of-parameters: In some places
the list-of-parameters is specified as containing a list of individual
parameter names or labels, but here it is specified as containing a list of
individual parameter names or a list of individual parameter labels. The
difference is significant: in the first case, the list-of-parameters can
contain a mix of names and labels, whereas in the second case it is
restricted to contain all names or all labels. I recommend that the
more-general mix be supported, which would require that 4.7.4.1.2.4 be
reworded. I marked the section with a comment but I did not make the change
myself.
7.       4.7.4.1.3.1(b), Cyclic Report START diagnostic: extends ‘unknown
parameter identifier’ to also cover parameter identifiers carried in
Parameter Labels.
8.       4.8.2.2, Notification Concepts: adds individual event labels.
9.       4.8.3.1.3, Notification Starting Behavior: adds support for event
labels.
10.   4.8.3.2, Notification Notifying Occurrence of Events Behavior: New
requirements added: (a) if an event name is used in the list-of-events, then
the corresponding notification-type parameter must use the event name; (b)
services and derived procedures must specify whether and under what
conditions event names or labels can be used in notification-type parameters
when the list-of-events contains an event label.
11.   4.8.4.1.2.2.2.2, Notification START list-of-events: add support for
event labels.
12.   4.8.4.1.3(b), Notification START diagnostic: extends ‘unknown parameter
identifier’ to also cover event identifiers carried in Event Labels.
13.   Annex B: New requirements added: (a) if a parameter name is used in the
list-of-parameters, then the corresponding qualified parameter must use the
parameter name; (b) services and derived procedures must specify whether and
under what conditions parameter names or labels can be used in qualified
parameters when the list-of-parameters contains a parameter label.
14.   E3.3, Common Types: extends the ListofParamEventsDiagnostics type to
allow for labels to be returned for the unknownParamEventIdentifier choice.

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.