[Css-csts] Accessible and modifiable configuration table items

John Pietras john.pietras at gst.com
Thu Jan 30 17:07:13 EST 2014


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).

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

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.

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.


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.

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.

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.

Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20140130/8b0c6f8b/attachment.html


More information about the Css-csts mailing list