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

Mon Jun 24 12:43:44 EDT 2013

Yves,
I think that there are two basic scenarios for using labels vs. names for parameters, notifications, etc. In the first scenario, there is at most one instance of each functional resource type associated with a particular CSTS instance. In such a case simple labels could be used with the expectation that the provider would "know" which functional resource instance applies. E.g., if the user of a CSTS asks for a parameter of that CSTS's FR Type, the user can simply use the label and the Provider CSSS will know that it applies to that CSTS instance. Similarly, the user could use the label to ask for (published) parameters for any production FR Type associated with that CSTS type (e.g., the carrier lock parameter value of the return space link carrier reception FR instance that provides that is reported by a RUFT CSTS instance). In this scenario I can imagine that labels would always (or almost always) be used. The service specification might have to specify that a label will only return the value that is directly associated with the CSTS instance (that is, for example, that a user of the RUFT service asking for the carrier lock status will only get the status associated with that RUFT service instance, and not the carrier statuses for all return space link carrier reception FR instances in the Service Package). 

The other case is when the CSTS must be able to access the parameters, notifications, etc., of multiple instances of FR Types (e.g., the MD-CSTS). In this case a Name can be used to identify a single instance of a parameter or event, or a Label can be used to identify all instances in the Service Package*. Until now Labels were used only in conjunction with predefined lists, but now we can extend this and put individual labels in the list of parameters or list of events. Here is where it might be useful to mix names and labels - e.g., "I want all instance of carrier lock in the Service Package [label] and the number of frames received for RAF instance 2 only [name]". This is the only case where I think it might be desirable to mix labels and names. It might also be done by using separate instances of the procedures. 
[* I say "in the Service Package" because there needs to be some way to scope what the label refers to. For the MD-CSTS and TD-CSTS, the scope is naturally the Service Package, but there might be other scopes for other CSTS types.]

I don't have a strong desire to see names and labels mixed in the same list, and I see that the ASN.1 is currently structured to not permit mixing. However, if  label and names are not permitted to be mixed, then perhaps you might want to remove the implication that they can be mixed the sections that currently say things like "a set of parameter names or labels" by changing them to something like "a set of parameter names or a set of parameter labels."

Best regards,
John

-----Original Message-----
From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int] 
Sent: Monday, June 24, 2013 10:42 AM
To: John Pietras
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org)
Subject: Re: Updated CSTS SFW on CWE - labels

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.

--
BEGIN-ANTISPAM-VOTING-LINKS
------------------------------------------------------

NOTE: This message was trained as non-spam.  If this is wrong, please correct the training as soon as possible.

Teach CanIt if this mail (ID 01JQeIc6i) is spam:
Spam:        https://filter.gst.com/canit/b.php?i=01JQeIc6i&m=d177912a8e0f&c=s
Not spam:    https://filter.gst.com/canit/b.php?i=01JQeIc6i&m=d177912a8e0f&c=n
Forget vote: https://filter.gst.com/canit/b.php?i=01JQeIc6i&m=d177912a8e0f&c=f
------------------------------------------------------
END-ANTISPAM-VOTING-LINKS