[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