[Css-csts] Effects of using individual Labels with MD-CSTS

Tue Jul 9 16:48:42 EDT 2013

Yves and CSTSWG colleagues ---
Yesterday I responded to Yves' message (see below). With regard to his question about whether the CSTS SFW should specify the behavior of an operation of a procedure when a Label is used in the subscription (e.g., can the return contain either a Label or a Name?), Yves expressed a preference for not locking it down in the CSTS SFW. I agreed with that preference, and suggested that the CSTS SFW could formally defer the specification of the behavior to the individual services. When I wrote my response yesterday, I thought that it would be sufficient to address the behavior as a refinement of some operation parameter values.

Yesterday and today I modified the MD-CSTS specification to address the the behavior with respect to what gets reported/notified when a Label is used in the subscription or query. Unfortunately, it looks like the effect on the MD-CSTS (and other services using the Cyclic Report and Notification procedures and the GET operation) may be more extensive than I had originally anticipated.

I've uploaded the modified MD-CSTS specification to the CWE at URL
http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/Future%20Services%20using%20Toolkit/MonitoredDataCSTS/MonitoredDataCSTS_W-0.15-13-07-09.doc

The complications arise because according to the CSTS Guidelines (most recent version posted on the CWE - October 2012), a change in or addition to  procedure behavior is defined as an extension, which in turn requires that a new Procedure Type Identifier be defined (along with a new name for the procedure) and a new procedure specification section to be added to the service specification.

I tried to figure out how to add the specification of such behavior in the service specifications without needing to create extended procedures, but so far I have not had success. The best thing that I have been able to think of so far is that we might define a standard set of behaviors in the CSTS SFW and require that a service specification select among them (sort of like how we have defined standard state machines from which each service specification selects the one to which it conforms). If we have a standard set of behaviors, a service that selects which of those behaviors that applies to it could be considered to be refining (instead of extending) the behavior, and that would not involve creating a new Procedure Type Identifier. The Guidelines would also have to change to allow refinement of behavior.

How should we proceed? Do we just accept that any service that uses the Cyclic Report or Notification procedure or any procedure that uses the GET operation will have to be extended (that is, it will be impossible to simply adopt the Framework version of the procedure), or should we try to figure out how to "standardize" this behavior in the Framework? I look forward to your (and other CSTSWG colleagues') responses.

Best regards,
John

From: John Pietras
Sent: Monday, July 08, 2013 11:57 AM
To: 'Yves.Doat at esa.int'
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org); css-csts-bounces at mailman.ccsds.org
Subject: RE: [Css-csts] RE: Updated CSTS SFW on CWE - labels

Yves,
My comments are interleaved below.

Best regards,
John

From: Yves.Doat at esa.int<mailto:Yves.Doat at esa.int> [mailto:Yves.Doat at esa.int]
Sent: Monday, July 08, 2013 2:37 AM
To: John Pietras
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>); css-csts-bounces at mailman.ccsds.org<mailto:css-csts-bounces at mailman.ccsds.org>
Subject: Re: [Css-csts] RE: Updated CSTS SFW on CWE - labels

Dear John,

Thanks for your reply.

1. No mixing of Names and Labels
As you did not really object I kept the definition as is not allowing the mixture of names and labels in a request.
The defined ASN.1 has not been changed and read as follows:
ListOfParametersEvents                        ::=        CHOICE
{        defaultList                        [0]        NULL
,        paramEventNames                [1]        SEQUENCE OF Name
,        paramEventLabels                [2]        SEQUENCE OF Label
,        listName                        [3]        VisibleString
,        functionalResourceName        [4]        FunctionalResourceName
}

My main argument to keep the definition as is, is simplicity. Allowing mixing would be possible but would introduce a complexity in the definition. The consequence of this approach is that a service user that will need to retrieve names and labels will have to issue two requests.
In case someone would have a concern with that approach please let me know.
As I stated in my earlier message, I have no objection to not allowing the mixture of Names and Labels. However, there two places in my proposed revised text ("921x1r2[Draft 201306] - Return Services-JVP") that imply that they could be mixed. Below are proposed rewordings:

a)      Section 3.11.2.3.1 (b), second sentence: change "The list of unknown Parameter Names and Parameter Labels shall be returned with the diagnostic."
to
"The list of unknown Parameter Names or Parameter Labels shall be returned with the diagnostic."

b)      Section 4.7.4.1.3.1 (b), second sentence: change "The list of unknown Parameter Names and Parameter Labels shall be returned with the diagnostic."
to
"The list of unknown Parameter Names or Parameter Labels shall be returned with the diagnostic."

2. Return of Names when Labels are requested:
Another aspect which you are addressing is what a service provider shall return in case a label is required. At the moment he can return a name or a label.
In your proposed scenario, in case the service provider only "knows" one name whether he returns a name or a label does not make any difference and can be accepted.
However in the case a service provider would "know" more than one name and return a label, the service user may be misled as he cannot be sure if the returned information is the requested on.

A solution would be to force the service provider only to return names. In case a service user would request a label and the service would "know" more than a name, he would return all "known" names. The service user would have to filter/search himself for the desired one. This would resolve the uncertainty but I am not sure is the service user would "know" how to filter.
The question is: Do we want the service provider to return only names and do not allow the return of labels? On one hand I adhere to this limitation, on the other hand this implementation would remove flexibility for the service definition and may be counter-productive.
Currently the definition allows the service provider to return names and labels.
This solution impacts the current definition and I would appreciate to get the position of the group members.
(In case my explanation is not clear we should discuss the topic in a next teleconference.)
It was my understanding from our discussion at the last telecon that we decided that if the user subscribed to a parameter or event using its Name, then the report/notification/etc. would have to use the full Name also. I don't believe that we had any decision on what has to be returned when a Label is used in the subscription. In "921x1r2[Draft 201306] - Return Services-JVP", I tried to address this by proposing explicit requirements that (a) state that a Name returns a Name, and (b) defers the decision about what gets returned in response to a Label to the service specifications that use that procedure.
Specifically, for the Notification procedure, the relevant requirements are:
4.8.3.2.3  If an event is subscribed in terms of an individual event name, the corresponding notification-type parameter (see 3.10.2.2.3.1) shall contain that event name.
4.8.3.2.4  The service specification or derived procedure shall specify the conditions under which it is permissible or required to use the event label or event name in a notification-type parameter that corresponds to an event that is subscribed in terms of an event label.
For the qualified parameters (which are returned for all procedures that deal with parameters) the relevant requirements are:
B2.3  If a parameter in the list-of-parameters parameter is identified by an individual parameter name, the corresponding qualified parameter shall include that parameter name.
B2.4 The service specification or derived procedure shall specify the conditions under which it is permissible or required to use the parameter label or parameter name in a qualified parameter that corresponds to a parameter in the list-of-parameters parameter that is identified by an individual parameter label.
If the CSTSWG agrees with this approach (Names result in Names, but the result of Labels is determined by the service) then I think the above requirements largely resolve the problem. The only resulting issue that I can think of is how such definition should be documented in the service specifications. I believe that since it would be a "down selection" of existing possibilities (Names, Labels, or Names and Labels) it should be treated as a refinement. Does this seem correct to the rest of the CSTSWG?
The procedures in some services may be perfectly unambiguous with returning labels - e.g., the production status of an SLE-like CSTS can be assumed to always apply to the production associated with that CSTS instance, and so the instance number is not necessary.
However, for something like the MD-CSTS, it will always be necessary to return full Names. I will revisit the MD-CSTS specification to ensure (a) that it handles individual Labels as well as Names in the list-of-parameters and list-of-events parameters and (b) that it is clear that Names are always returned regardless of whether Names or Labels are used in the subscriptions. If we agree that this should be treated as a refinement, then I'll make the appropriate changes to the MD-CSTS specification.

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/
__________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130709/b49644b3/attachment-0001.html