[Css-csts] RE: Updated CSTS SFW on CWE - labels
John Pietras
john.pietras at gst.com
Mon Jul 8 11:57:03 EDT 2013
Yves,
My comments are interleaved below.
Best regards,
John
From: 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); 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/
__________________________________________________
From:
John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>
To:
"Yves.Doat at esa.int<mailto:Yves.Doat at esa.int>" <Yves.Doat at esa.int<mailto:Yves.Doat at esa.int>>
Cc:
"CCSDS_CSTSWG \(css-csts at mailman.ccsds.org\<mailto:css-csts at mailman.ccsds.org\>)" <css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>>
Date:
24/06/2013 18:44
Subject:
[Css-csts] RE: Updated CSTS SFW on CWE - labels
Sent by:
css-csts-bounces at mailman.ccsds.org<mailto:css-csts-bounces at mailman.ccsds.org>
________________________________
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> [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<mailto: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<mailto:john.pietras at gst.com>>
To: "Yves.Doat at esa.int<mailto:Yves.Doat at esa.int>" <Yves.Doat at esa.int<mailto:Yves.Doat at esa.int>>
Cc: "CCSDS_CSTSWG (css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>)" <css-csts at mailman.ccsds.org<mailto: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
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org<mailto:Css-csts at mailman.ccsds.org>
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
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.
________________________________
NOTE: This message was trained as non-spam. If this is wrong, please correct the training as soon as possible.
Spam<https://filter.gst.com/canit/b.php?i=01JVGD5Cd&m=d988ac5b5ef9&c=s>
Not spam<https://filter.gst.com/canit/b.php?i=01JVGD5Cd&m=d988ac5b5ef9&c=n>
Forget previous vote<https://filter.gst.com/canit/b.php?i=01JVGD5Cd&m=d988ac5b5ef9&c=f>
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130708/19b6d306/attachment-0001.html
More information about the Css-csts
mailing list