[Css-csts] Fw: Framework document and OID Tree spreadsheet for CSTS review on CWE

[Holger.Dreihahn at esa.int]

On behalf of Wolfgang.
Dear CSTS WG members, 

I have uploaded to the CWE (Cross Support Services Area (CSS) > Documents 
> CSS-CSTS > CWE Private > CSTS Framework and Concept) both the latest 
version of the CSTS Framework document  as well as the most recent version 
oft he OID tree spreadsheet. These uploaded versions are now the input to 
the review by the CSTS Working Group. In what follows, I provide a summary 
oft he changes implemented since our last CSTS telecon.
 
  
The references to Service Management books have been updated as per John?s 
input. However, there are doubts that in a book to hopefully go blue in 
2014 we can have normative references to books scheduled to be published 
in 2017. Margherita is in the process of clarifying this issue.

The directive-identifier parameter in the EXECUTE-DIRECTIVE invocation is 
now of the type Published Identifier. The body of the document and the 
ASN.1 have been updated accordingly. Furthermore, the Sequence-Controlled 
Data Processing procedure now contains the OID specification of the 
'reset' directive-identifier and the OID tree has been modified 
accordingly. Figure K-4 has been replaced as to show the most recent 
version oft he Framework OIDs. 

The transfer buffer terminology has been updated. The buffer used for data 
units received from the service user is referred to as forward buffer. The 
buffer used for data units to be sent to the service user is referred to 
as return buffer. Both the body of the document including figures 4-1 and 
4-2  as well as the ASN.1 have been modified accordingly. Both types of 
buffers are now covered by the CSTS PDU type specified in E3.15 and the 
export and import statements have been updated. 

The OID tree has been updated to now use the term tracking (rather than 
radiometric) service and fig. K-5 has been changed accordingly.
The terms ?Label List? and ?Label List Set? have been added to section 
1.6.1.4.

The IQ procedure permits to retrieve the name and contents of all 
parameter lists defined in the context of a given service and the default 
list is tagged as being the default list in the set of returned list 
names. However, there is no query that would only return the default list. 
For hat reason, the default list is marked as not accessible in the 
procedure configuration parameters tables. A NOTE has been added (see e.g. 
4.9.5.1) that explains why the default list is stated to be not 
accessible. This modification applies also to the CR and N procedures.

The set of parameter lists is no longer qualified as being dynamically 
modifiable. There is no need to provide such capability as the user can 
query anyway any set of parameters by using the corresponding labels in 
the START invocation. This update applies both to the IQ and the CR 
procedures.
The parenthetical ?(Functional Resource Types and Instances)? appearing in 
some of the tables specifying the procedure configuration parameters was a 
left-over from earlier versions and has now been removed. The tables 
defining the procedure specific configuration parameters have been cleaned 
up and do now reference the relevant data type specifications added to 
E3.16.

The GET diagnostics have not been modified as it occurs to me that the 
scenarios where appropriate diagnostics were felt to be missing cannot 
happen in the light of the Framework specifications. In the event that I?m 
wrong, we shall of course update the diagnostics as needed.

In the ASN.1, all CHOICE tags are now in sequence without gaps. The 
reference to the (not existing) 
DataProcessingNotifyInvocNotificationTypeExtension has been removed. 

The NOTIFY invocation as used by the BDP and SCDP procedures was 
incorrectly specified in the sense that the required types in the ASN.1 
were completely redefined ignoring what was inherited due to the fact that 
both the BDP and SCDP procedures are derived from the DP procedure. For 
the processCompletionReport it has now been taken into account that 
SequContrDataProcProcDataInvocExt and BuffDataProcProcDataInvocExt inherit 
this from the base procedure's DataProcProcDataInvocExt type.
 
The DataProcNotifyInvocExt has been cleaned up such that what the BDP and 
SCDP procedures inherit from the base DP procedure has now been taken into 
account. The specifics of the data processing status required by the SCDP 
procedure are implemented by means of a further extension 
(statusExtension) which is used only by the SCDP procedure. 
 
Events and the associated notifications associated with service production 
(including production related configuration changes) have been cleanly 
separated from procedure related events. All events have been moved to the 
appropriate places in the OID tree and partially relabeled. The 
svcConfigurationChange related notification has been modified such that 
for this case the eventValue is empty as at framework level the 
service-specific production related configuration parameters are not 
known. This has also the advantage that now all service or production 
related events are in this respect identical: the eventValue is always 
empty. 
 
For the procedures of which at least one configuration parameter might be 
modified while the service instance executing the procedure is bound, 
procedure-type-specific events have been defined (pBDDconfigurationChange, 
pDPconfigurationChange, pBDPconfigurationChange and 
pSCDPconfigurationChange). For each of these notifications, a specific 
CHOICE for the eventValue has been defined so that the modified 
configuration parameter setting is reported as part of the 
procedure-specific configuration change notification. It should be noted 
that as to obtain these configuration change notification, the service has 
to support the Notification procedure and the user has to subscribe to 
these events. All procedures that have dynamically modifiable parameters 
include the NOTIFY operation, but in my view this is by coincidence rather 
than design and therefore I have not envisaged that these procedures use 
the NOTIFY operation directly for the configuration change event. This has 
also the advantage that the user can control which events shall be 
notified. 

The missing ?locked? event has been added to the SCDP procedure.
 
There were a few issues where similar cases were handled not in similar 
ways. For the sake of improved consistency the following changes have been 
introduced: 
 
The delivery mode of the BDD procedure is now an accessible configuration 
parameter (for consistency with the BDP procedure, where the 
data-transfer-mode is accessible.
The named lists of events are now an accessible configuration parameter of 
the N procedure for consistency with the IQ procedure where the the named 
lists of labels are accessible. 
 Additional event types are now consistently treated as a 
notification-type refinement rather than an extension as was done in 
comments in the ASN.1.
 
In addition, various editorial bugs discovered by David, John and Yves 
have been corrected. Many thanks for reporting those to me. I also found 
and corrected a number of minor things (e.g. most of the figures did not 
show up in the list of figures of the ToC). I?m sure that there are more 
issues, but hopefully they will be found during the 2-weeks CSTS review 
period that starts now.
 
Happy reading and best regards,
 
Wolfgang 
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/20140219/cb0de9c2/attachment.htm