<font size=3>Dear WG Members,</font>
<br><font size=3>please look at Wolfgang's e-mail relevant to the
final round of updates to the CSTS SFW.</font>
<br><font size=3>I am trying to sort out with the e-mail administrator,
why Wolfgang's e-mails do not reach the WG distribution list.</font>
<br><font size=3>Kind regards,<br>
Margherita<br>
<br>
-------- Weitergeleitete Nachricht -------- </font>
<table width=346 style="border-collapse:collapse;">
<tr height=8>
<td width=57 valign=top style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;">
<div align=right><font size=3><b>Betreff: </b></font></div>
<td width=289 style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><font size=3>Status
of the SFW Updates</font>
<tr height=8>
<td width=57 valign=top style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;">
<div align=right><font size=3><b>Datum: </b></font></div>
<td width=289 style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><font size=3>Sat,
07 Feb 2015 12:24:19 +0100</font>
<tr height=8>
<td width=57 valign=top style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;">
<div align=right><font size=3><b>Von: </b></font></div>
<td width=289 style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><font size=3>Wolfgang
Hell </font><a href="mailto:Wolfgang_._Hell@t-online.de"><font size=3 color=blue><u><Wolfgang_._Hell@t-online.de></u></font></a>
<tr height=8>
<td width=57 valign=top style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;">
<div align=right><font size=3><b>An: </b></font></div>
<td width=289 style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><a href="mailto:css-csts-bounces@mailman.ccsds.org"><font size=3 color=blue><u>css-csts-bounces@mailman.ccsds.org</u></font></a></table>
<br><font size=3><br>
</font>
<p><font size=3>Dear CSTS colleagues,</font>
<p><font size=3>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 </font>
<p><a href=http://cwe.ccsds.org/css><font size=3 color=blue><u>Cross Support
Services Area (CSS)</u></font></a><font size=3> > </font><a href="http://cwe.ccsds.org/css/docs/Forms/AllItems.aspx?View=%7B8045374D-F8E0-4356-83CA-993252A38FE8%7D"><font size=3 color=blue><u>Documents</u></font></a><font size=3>
> </font><a href="http://cwe.ccsds.org/css/docs/Forms/AllItems.aspx?RootFolder=%2Fcss%2Fdocs%2FCSS%2DCSTS&View=%7B8045374D-F8E0-4356-83CA-993252A38FE8%7D"><font size=3 color=blue><u>CSS-CSTS</u></font></a><font size=3>
> </font><a href="http://cwe.ccsds.org/css/docs/Forms/AllItems.aspx?RootFolder=%2Fcss%2Fdocs%2FCSS%2DCSTS%2FCWE%20Private&View=%7B8045374D-F8E0-4356-83CA-993252A38FE8%7D"><font size=3 color=blue><u>CWE
Private</u></font></a><font size=3> > CSTS Framework and Concept</font>
<p><font size=3>and the file name is "921x1r2 20150207".
</font>
<p><font size=3>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:</font>
<p><font size=3 color=#4181ff>Dear CSTS colleagues, <br>
<br>
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 <br>
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. <br>
<br>
The most substantive changes beyond those triggered by the official RIDs
are the following: <br>
<br>
- 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. <br>
- 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. <br>
- The language regarding the conditions for IQ GET and N and CR START invocations
to be valid has been improved / corrected. <br>
- 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. <br>
- 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. <br>
- 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. <br>
<br>
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. <br>
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.
<br>
<br>
Best regards, <br>
Wolfgang </font>
<p><font size=3>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.</font>
<p><font size=3>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.</font>
<p><font size=3>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.</font>
<p><font size=3>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.</font>
<p><font size=3> </font>
<p><font size=3><b>Open items:</b></font>
<p><font size=3><b>Item 1:</b></font>
<p><font size=3>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:</font>
<p><font size=3> </font>
<p><font size=3>SequContrDataProcStatus ::=
CHOICE</font>
<p><font size=3>{ expired
[3] NULL</font>
<p><font size=3>, processingNotStarted [4] NULL</font>
<p><font size=3>}</font>
<p><font size=3>should be changed to</font>
<p><font size=3> </font>
<p><font size=3>SequContrDataProcStatus ::=
CHOICE</font>
<p><font size=3>{ expired
[3] NULL</font>
<p><font size=3>, processingNotStarted
[4] NULL</font>
<p><font size=3>, sequContrDataProcStatusExt [5]
Extended</font>
<p><font size=3>}</font>
<p><font size=3>and</font>
<p><font size=3> </font>
<p><font size=3>SequContrDataProcExecuteDirectiveInvocExt ::=
NextDataUnitId</font>
<p><font size=3>should be changed to</font>
<p><font size=3> </font>
<p><font size=3>SequContrDataProcExecuteDirectiveInvocExt ::=
CHOICE</font>
<p><font size=3>{ nextDataUnitId
[1]
NextDataUnitId</font>
<p><font size=3>, scdpExecuteDirectiveInvocExtExtension [2]
Extended</font>
<p><font size=3>}</font>
<p><font size=3> </font>
<p><font size=3><b>Item 2:</b></font>
<p><font size=3>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:</font>
<p><font size=3> </font>
<p><font size=3>Appellation
::= CHOICE</font>
<p><font size=3>{ string
[0] VisibleString (FROM (ALL EXCEPT " "))</font>
<p><font size=3>, nameExtension [1]
Extended</font>
<p><font size=3>}</font>
<p><font size=3>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.</font>
<p><font size=3><b>Item 3:</b></font>
<p><font size=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?</font>
<p><font size=3><b>Item 4:</b></font>
<p><font size=3>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.</font>
<p><font size=3><b>Item 5:</b></font>
<p><font size=3>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? </font>
<p><font size=3><b>Item 6: </b></font>
<p><font size=3>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.</font>
<p><font size=3><b>Item 7: </b></font>
<p><font size=3>I will complete the records of what has been changed in
the document by means of two documents:</font>
<p><font size=3>-
The dispositioning of the official RIDs</font>
<p><font size=3>-
The response to the numerous comments and suggestions after the official
review.</font>
<p><font size=3>Looking forward to your feedback. </font>
<p><font size=3>Best regards,</font>
<p><font size=3>Wolfgang</font>
<p><font size=3><br>
<br>
</font>
<br><PRE>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.
</PRE>