[Css-csts] Fw: Status of the SFW Updates

Mon Feb 9 10:11:35 UTC 2015

Dear WG Members,
please look at Wolfgang's  e-mail relevant to the final round of updates 
to the CSTS SFW.
I am trying to sort out with the e-mail administrator, why Wolfgang's 
e-mails do not reach the WG  distribution list.
Kind regards,
Margherita

-------- Weitergeleitete Nachricht -------- 
Betreff: 
Status of the SFW Updates
Datum: 
Sat, 07 Feb 2015 12:24:19 +0100
Von: 
Wolfgang Hell <Wolfgang_._Hell at t-online.de>
An: 
css-csts-bounces at mailman.ccsds.org

Dear CSTS colleagues,
As regards the SFW, I believe that I?m seeing (blue) light at the end of 
the tunnel. I?m optimistic that it is not just a train coming against me. 
I have uploaded the current version of the document to 
Cross Support Services Area (CSS) > Documents > CSS-CSTS > CWE Private > 
CSTS Framework and Concept
and the file name is "921x1r2 20150207".    
Firstly, here is a copy of the email that I had sent out prior to our 
recent telecon  that I retrieved from my ?sent? folder, but apparently it 
never made it to any of you. I never got any error message. Perhaps this 
was due to the high volume attachment ? or for whatever reason the CCSDS 
mailman has stopped to consider me a legitimate user. If I don?t receive 
this mail back from the CCSDS mailman, I?ll notify Margherita and we?ll 
see with the administrator what needs to be done to get that problem 
fixed. This time I have uploaded the present status of the SFW to the CWE 
rather than trying to send it as an attachment (see above). And here is 
the email that got lost:
Dear CSTS colleagues, 

My original intent was to have the SFW updates completed for this 
forthcoming telecon, but I got sidetracked to some CSA activity. As a 
consequence, what I can provide at this point is only a snapshot of work 
in progress. However, having said that I believe it is fair to state that 
the SFW is in relatively good shape. All officially submitted R-2 RIDs 
have been processed and the document updated accordingly, including 
feedback from the RID authors in a few cases. In addition to these 
official RIDs, I received a lot of invaluable input from John. Given that 
he worked on the MD service specification, he was the first SFW user and 
consequently suffered from all the errors and imperfections. I will create 
a document summarizing John's feedback and the resulting SFW updates 
before the SFW is sent to the secretariat, but for the telecon this would 
be far too much detail. 

The most substantive changes beyond those triggered by the official RIDs 
are the following: 

- The upper bound of the delivery cycle of the Cyclic Report has been 
lifted. The minimum delivery cycle is now a CR configuration parameter. 
The resolution of the delivery cycle parameter has been changed to 
milliseconds. 
- As to simplify the specification of the scope of refinements, the 
specification of the effect of the list-of-parameters parameters has been 
restructured so that the different cases (FR parameter names, FR parameter 
labels, procedure configuration parameter names, procedure configuration 
parameter labels) are covered by separate requirements. 
- The language regarding the conditions for IQ GET and N and CR START 
invocations to be valid has been improved / corrected. 
- Given the outcome of the London meeting that Service Packages and 
Configuration Profiles will provide CSTSes users with the FR instance 
numbers, we have lifted the original limitation that labels had to be 
associated with a single instance of a given FR. 
- PICs proforma (annex G) was flawed in the sense that extension only 
permitting additional values (mostly for the diagnostic parameter) were 
presented as if the were introducing additional parameters to the PDUs. 
Fixing this issue required a major rewrite of that annex. 
- The comments in the ASN.1 (annex E) dealing with extensions needed to be 
reworked accordingly. They are now more comprehensive and specific. As a 
courtesy to the reader I plan to still enhance these comments with more 
cross references so that one can navigate in the document more easily. Due 
to the open issue in the document addressed below, the updates associated 
with notifications are pending. 

John brought up a very valid concern mostly regarding the way the SFW 
specifies event values. I hope that John will participate in the telecon 
and will provide an introduction to this topic. Otherwise I will try. John 
also suggested how we could improve the SFW and it looks okay to me. But 
before going ahead with this change, I would appreciate the feedback from 
other CSTS members. 
John also made a proposal on how to improve the link between the body of 
the document and the formal type definitions in annex E. What John 
suggests is in my mind an improvement and I don't mind implementing it. 
But if are are desperate to get the book to the secretariat as soon as 
possible, we could take the position that this is nice-to-have perfecting 
of the book, but not absolutely necessary. We should talk about this at 
the telecon. 

Best regards, 
Wolfgang 
After the telecon I continued working on the SFW. I have revised one more 
time annex G (PICS proforma) which in particular in terms of reference 
paths for extensions was not fully consistent as correctly pointed out by 
John to me. I think with this update I taken care of all concerns 
expressed by John. I hope that what is now in the book is also consistent 
with what John needs for the MD service specification.
I have changed the NotificationTypes ASN.1 specification as agreed at the 
telecon as to create the desired flexibility for expressing the 
event-value parameter. I have also updated the document where it was 
affected by this revised type specification. Based on an email from John I 
have doubts if what I have done was really what he had in mind. Please 
refer to the list of open items below for details.
I have also reworked all comments in annex E that are related to 
extensions. I believe they are consistent now and that I removed false 
statements that were related to the confusion of extensions adding 
parameters and extensions only adding permissible values for a given 
parameter.
I have also restructured those parts of the document where the parameters 
of a given operation are specified as per John?s proposal, however I kept 
the headings as an aid to the reader when looking for the definition of a 
specific parameter listed in the associated table. If it is felt that 
these headings unnecessarily inflate the document, they can be removed in 
a few minutes.

Open items:
Item 1:
While working through all extensions as specified in the ASN.1, I 
discovered that for now we have two extensions that opposite to the 
general convention cannot be extended further. It is quite likely that I?m 
to be blamed for that and probably preventing further extension was not 
the intention. This can be easily corrected, but is of course a change of 
the ASN.1. The impact on the prototyping is in my view negligible, but I 
would prefer to get that confirmed before changing the document. Here are 
the two types that should be modified:

SequContrDataProcStatus    ::=   CHOICE
{  expired              [3]   NULL
,  processingNotStarted [4]   NULL
}
should be changed to

SequContrDataProcStatus    ::=   CHOICE
{  expired                       [3]   NULL
,  processingNotStarted          [4]   NULL
,  sequContrDataProcStatusExt    [5]   Extended
}
and

SequContrDataProcExecuteDirectiveInvocExt ::=   NextDataUnitId
should be changed to

SequContrDataProcExecuteDirectiveInvocExt ::=   CHOICE
{  nextDataUnitId                         [1]        NextDataUnitId
,  scdpExecuteDirectiveInvocExtExtension  [2]   Extended
}

Item 2:
Some diagnostics make use of the Appellation type which apparently is 
intended to provide additional information so that it is easier to figure 
out what caused the error resulting in a negative return. However, the 
type definition is as follows:

Appellation             ::=   CHOICE
{  string            [0]   VisibleString (FROM (ALL EXCEPT " "))
,  nameExtension     [1]   Extended
}
Given that the extension is not constrained in the SFW in any way and will 
most likely vary depending on the peer entities communicating, I see a 
high risk that this will result in interoperability problems. If we feel 
strong about retaining this flexibility then we probably should make 
stronger statements such as Appellation must not be extended except such 
extension has been agreed between the CSTS user and provider entities. It 
also raises the question where in the tree the required OIDs shall be 
accommodated if we permit such private bilateral extensions.
Item 3:
The revised type specification of NotificationTypes now permits taking 
advantage of the flexibility offered by the TypeAndValue type for 
expressing event-value parameter values. For the configuration change 
events specified in the SFW I have taken advantage of this. However, one 
still has the option to specify an event-value parameter by means of an 
extension. This has the advantage that in the type specification one can 
be very specific but the drawback is that one needs to specify also an OID 
for each event-value parameter. If this is what we want, the flexibility 
we introduced by means of the TypeAndValue type is not really providing a 
benefit. What is the preferred approach?
Item 4:
The ASN.1 syntax check has not yet been performed. I will create the input 
to the compiler and send it to Holger for checking.
Item 5:
For various reasons it would be beneficial to come up with shorter strings 
in the ASN.1. I?m reluctant to introduce changes before knowing that what 
we have right now is syntactically correct. Is it worth spending effort on 
this? 
Item 6: 
Given the huge number of updates, it is quite likely that I introduced 
some errors, formatting issues and typos. I will go through the document 
again, but will appreciate any feedback that you can provide.
Item 7:    
I will complete the records of what has been changed in the document by 
means of two documents:
-          The dispositioning of the official RIDs
-          The response to the numerous comments and suggestions after the 
official review.
Looking forward to your feedback. 
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/20150209/7326667a/attachment.html>