[Css-csts] RE: NotificationTypes

[John Pietras]

Yves,
I am sorry that I have not been able to respond to your email until now - the GST email server and connectivity to the outside world failed over the weekend and were restored just a short time ago.

I think that your additions are fine, However, I did make a few additional proposals in the email "parameter labels and event labels", (22 January 2013) and included them in the document “921x1r2[Draft 201301] - Return Services-JVP+YD+labels” (http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/CSTS%20Framework%20and%20Concept/921x1r2%5BDraft%20201301%5D%20-%20Return%20Services-JVP+YD+labels.doc). 
That most-recent version proposed three additional terms: Parameter Label, Event Label, and Directive label. Those names were proposed to be used not only in the (renumbered) annex D but also in the list of additional definitions in 1.6.1.4. For your convenience in reading, here are the additional definitions that I proposed for 1.6.1.4 and the renumbered Annex D:

In 1.6.1.4:
Directive Label: consists of a Directive Identifier that represents an individual directive type, and a Functional Resource Type that represents the Functional Resource Type with which that directive type is associated (see ANNEX D).
Event Label: consists of an Event Identifier that represents an individual event type, and a Functional Resource Type that represents the Functional Resource Type with which that event type is associated (see ANNEX D).
Parameter Label: consists of a Parameter Identifier that represents an individual parameter type, and a Functional Resource Type that represents the Functional Resource Type with which that parameter type is associated (see ANNEX D).

In Annex D:
PARAMETER LABEL   A parameter label shall be composed of a Functional Resource Type published identifier and a Parameter Identifier.
EVENT LABEL               An event label shall be composed of a Functional Resource Type published identifier and an Event Identifier.
DIRECTIVE LABEL       A directive label shall be composed of a Functional Resource Type published identifier and a Directive Identifier.

(Note - as proposed, parameter and event lists would now be defined as lists of parameter labels and event labels, respectively.

As I stated in the email of 22 January (see below), I found a need for the "label" concept while working through the update of the MD-CSTS specification. 

The addition of the "label" concept would result in few changes to the material that has already been proposed. However, I realize that it might be too late to make changes to your copy in time to get it posted on the CWE in time for Thursday's CSTSWG telecon. I ask that you and the rest of the CSTSWG think about these proposed changes so that we can discuss them at the Thursday telecon.

Best regards,
John

----------------
From: John Pietras 
Sent: Tuesday, January 22, 2013 5:12 PM
To: CCSDS_CSTSWG (css-csts at mailman.ccsds.org)
Subject: parameter labels and event labels

CSTSWG colleagues ---
Last month, I wrote a new normative annex that I have proposed for inclusion in the CSTS SFW Red Book. That annex (which I put in as Annex D) provides some normative definitions regarding Functional Resource Types, FR Identifiers, parameter identifiers, parameter names, and how they relate to parameter list contents. IN that annex, I had specified that a parameter list (either named or the default list) logically consisted of one or more parameter list records, where a parameter list record was defined as the combination of parameter identifier and Functional Resource Type (where Functional Resource Type is a published identifier, which in turn is, an ISO Object Identifier). At a previous time, our concept was that a parameter list would contain parameter names, but since parameter names include (by definition) the Functional Resource Instance Number (which is only instantiated by Service Management when the Service Package is scheduled) it became necessary to define lists (which exist before and outside of any scheduled Service Package) in terms of things without Functional Resource Instance Numbers. Thus the [parameter identifier : Functional Resource Type] pairs that constitute the list records are used to identify all instances of the parameter type represented by the Parameter Identifier for all instances of the Functional Resource Type that are configured to execute as part of the Service Package. 

This month (January), I started updating the draft Monitored Data CSTS Red Book to reflect the various changes that have occurred in the CSTS SFW since the last MD-CSTS draft was produced. Most of those changes have to do with the intermediate evolution of concepts and terminology related to Functional Resource, Parameter Names, etc.  While going through the updating process, I realized that the [parameter identifier : Functional Resource Type] pair had broader applicability than just defining the contents of a parameter list. I realized that SANA will have to register these pairs regardless of whether they are used in the construction of parameter lists. That is because it is not always sufficient to just use the parameter identifier to determine the Functional Resource Type with which that parameter identifier is associated. Specifically, when a framework parameter identifier (or framework event identifier) is “attached” to a Functional Resource Type, this relationship must be identified in terms of both the framework identifier and the FR Type. 

Given this more-general use of the [parameter identifier : Functional Resource Type] pair, the term “parameter list record” is inadequate because it implies that it is only used for lists. I am proposing a new term – parameter label – for this pair. Similarly, I propose event label as the name for the [event identifier : Functional Resource Type] pair.  

The effects on the CSTSSFW itself are minor – essentially addition of these label definitions (and one for directive label for future use) and replacing in a few places phrases such as “the combination of a Parameter Identifier and a Functional Resource Type” with the more-compact “parameter label”. I’ve made these changes in another draft of the CSTS SFW, this one titled “921x1r2[Draft 201301] - Return Services-JVP+YD+labels”. It contains all changes of the past few draft updates. I’ve uploaded it to the CWE at URL http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/CSTS%20Framework%20and%20Concept/921x1r2%5BDraft%20201301%5D%20-%20Return%20Services-JVP+YD+labels.doc. 

Best regards,
John