[Css-csts] RE: Updated CSTS SFW on CWE - labels
Yves.Doat at esa.int
Yves.Doat at esa.int
Mon Jul 8 02:36:33 EDT 2013
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.
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.)
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:
24/06/2013 18:44
Subject:
[Css-csts] RE: Updated CSTS SFW on CWE - labels
Sent by:
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]
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
_______________________________________________
Css-csts mailing list
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130708/d9d91bfe/attachment.html
More information about the Css-csts
mailing list