[Css-csts] Fw: Accessible and modifiable configuration table items

[Margherita.di.Giulio at esa.int]

----- Forwarded by Margherita di Giulio/esoc/ESA on 07/02/2014 09:23 -----

From:   Wolfgang Hell <Wolfgang_._Hell at t-online.de>
To:     John Pietras <john.pietras at gst.com>, "Wolfgang.Hell at esa.int" 
<Wolfgang.Hell at esa.int>, 
Cc:     "CCSDS_CSTSWG (css-csts at mailman.ccsds.org)" 
<css-csts at mailman.ccsds.org>, "Margherita.di.Giulio at esa.int" 
<Margherita.di.Giulio at esa.int>
Date:   06/02/2014 11:56
Subject:        Re: Accessible and modifiable configuration table items



John,

In the meantime I managed to take a careful look at your inputs. For 
convenience I have interspersed my responses with your original message.

Margherita,

If once again the CCSDS mailman does not distribute my email, can you 
please forward it to the distribution list? Thank you.

Best regards,
Wolfgang

Am 30.01.2014 23:07, schrieb John Pietras:
Wolfgang,
I am confused about what the configuration parameter tables for the Info 
Query, Cyclic Report and Notifications procedures are telling us. For 
example, Table 4-51 (Info Query Configuration Parameters) lists ?default 
list of parameters? as being neither accessible nor dynamically 
modifiable.  However, if I query the pIQlabelLists parameter (from the 
ASN.1) for an IO procedure instance, I will get a Label List Set that 
contains all of label lists for that procedure instance: the name of each 
list, whether it is the default list, and every single label in each list 
(which of course includes the default list). If ?accessible? means that it 
is able be read through a query, then to my thinking I have just 
?accessed? the default list of parameters (actually the default list of 
parameter labels).
We are in complete agreement of what is happening when one queries the 
pIQlabelLists parameter. I also agree that by doing so one can find out 
which of the label lists if any is set up to act as the default list. 
However, there is no query which would return only the name of the default 
list and in that sense, this parameter is not accessible. I?m assuming 
that it won?t be modifiable on the fly either as I?m assuming that the 
content of the default list will be negotiated well in advance of any 
service provision and then kept as per the agreement reached between the 
cross-support parties. I?m certainly willing to add some words to the 
Framework document that make clearer what not accessible means in this 
context. 
The table also includes the parameter ?named list of gettable parameters? 
(of type LabelList), which is identified as being both accessible and 
dynamically modifiable. I agree that the label lists are accessible using 
the pIQlabelLists parameter mentioned above. However, I do not agree that 
the lists should be dynamically modifiable, which means that the user can 
(somehow) create new label lists on the fly. All of our discussion 
regarding these lists have always been in the context that they are 
defined and instantiated in the appropriate operational databases well 
ahead of time. If a user needs to use a set of labels for which a 
pre-defined list does not exist, the user can simply invoked the GRT 9in 
this case) with the individual labels of interest in the 
list-of-parameters.
I agree with you that given that the user has the freedom to compose a set 
of parameter labels as may be required for a specific operational scenario 
and given that that capability exists we can avoid the complications that 
the dynamic creation of new label lists will imply. I will go ahead and 
modify table 4-51 such that the Information Query procedure does not have 
any dynamically modifiable configuration parameter.
If we want to match the contents of table 4-51 to what is actually 
supported by the ASN.1,  the ?default list of parameters? and the ?named 
list of gettable parameters? configuration parameters would collapse into 
a single ?lists of gettable parameter labels? parameter (of type 
LabelListSet) that is accessible but not dynamically modifiable.
For the reason discussed in my response to your first paragraph I prefer 
to keep the default list separate from the label lists.
 Table 4-51 also has the ?gettable parameter labels? parameter, which is 
listed as neither accessible nor modifiable. I?ll come back to this in a 
moment.
  Table 4-58 (Cyclic Report Configuration Parameters) has the parameters ?
list-names and the parameter labels that they represent? (accessible and 
modifiable, and of type LabelList) and ?default list and the parameter 
labels that it represents? (neither accessible nor modifiable, type N/A). 
But as in the case above, I can query the pCRlabelLists parameter and get 
the names and contents of all named label lists, including the default 
list. So (as above) I would argue that the default list is accessible. 
However, there is no configuration parameter that addresses the 
non-default label lists, although these clearly will also be return with a 
query of the the pCRlabelLists parameter.  Both cases (default and 
non-default label lists)  could be collapsed into a single ?lists of 
reportable parameter labels? parameter (type LabelListSet, accessible but 
not modifiable). 
 Table 4-58 also has the ?list-of-parameters (Functional Resource Types 
and Instances)? parameter, which is listed as neither accessible nor 
modifiable. The cross-reference is given and the list-of-parameters 
parameter of CR START invocation, which I take to mean the contents of the 
list-of-parameters parameter (as opposed to the contents of the label 
lists that have been created). However, I don?t understand what the 
parenthetical ?(Functional Resource Types and Instances)? means.
For the same considerations as discussed for the Information Query 
procedure, I will modify table 4-58 of the Cyclic Report procedure such 
that the label lists cannot be modified dynamically, i.e. new lists cannot 
be created on the fly. With that change in place, the Cyclic Report 
procedure does not have any dynamically modifiable parameters. Yves 
confirmed to me on the phone that the parenthetical ?(Functional Resource 
Types and Instances)? is a no longer needed leftover from earlier 
Framework versions and I will delete it.
 
Table 4-66 (Notification Configuration Parameters) has the ?individual 
notifiable events?, ?list-of-events and their names (Functional Resource 
Types and Instances)?, and ?default list of events? parameters, all of 
which are listed as non-accessible and non-modifiable. The default list is 
accessible through query of the pNlabelLists parameter. 
 The ?list-of-events and their names (Functional Resource Types and 
Instances)? parameter refers to the contents of the list-of-events 
parameter of the Notification START invocation, but I remain confused 
about the meaning of the parenthetical ?(Functional Resource Types and 
Instances)?. Also, I think the reference given in the table 
(4.11.4.1.2.2.1) is incorrect ? it should either be 4.11.4.1.2.2 or 
4.11.4.1.2.2.2.
As in table 4-58, the parenthetical ?(Functional Resource Types and 
Instances)? is a leftover from earlier Framework versions and I will 
delete it. Also I agree to change the reference for list-of-events to 
4.11.4.1.2.2.
 
I have argued before the ?individual notifiable events? parameter does not 
belong in the table. The reference in the table is to the paragraph that 
states that a derived procedure or service can add new events. This is 
basically the extension parameter, and we decided a long time ago to not 
call out the extension parameters. If and when a derived procedure  or 
service adds new events, those events will simply be events that are 
accessible (or not) via the existing query parameters. They are not 
configuration parameters in themselves. This parameter does not belong in 
this table.
 Now, returning to the ?gettable parameter labels? parameter in table 
4-51: neither the CP nor the Notification procedure have equivalent ? 
configuration? parameters. And why are just the labels called out ? can?t 
a similar case be made for all of the things that can be put into the 
list-of-parameters: Parameter Names, FR Types, FR Names, Procedure type, 
or procedure instance identification? I am not arguing that these *should* 
all be put in all three tables, but I question why only one of the 
possibilities was put in only one of the three tables where such 
parameters would presumably exist.
Looking at the specifications of the IQ, CR and N procedures, they all 
state that the accessible parameters are to be determined by the service 
using the procedure or by a procedure derived from one of the above listed 
procedures. This is why the notion of queriable parameters, reportable 
parameters and notifiable events shows up in the procedure specifications. 
Hence, the ?visible? parameters are chosen at the time of the service or 
derived procedure is specified. I therefore agree that this is NOT a 
matter of configuration and I will remove the corresponding rows from the 
tables listing the configuration parameters.
 
Finally, it would probably also be helpful to add Label List and Label 
List Set to section 1.6.1.4, Additional Definitions. If you would like, I 
can take a shot at writing some definitions.
I agree that it will be helpful to have Label List and Label List Set 
added to section 1.6.1.4. I will gratefully accept definitions that you 
will provide.
 
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20140207/a843e604/attachment.htm