[Css-csts] URGENT: Discrepancy in the SFW regarding the NOTIFY invocation

[Holger.Dreihahn at esa.int]

Dear Wolfgang and John,
I fully agree with your approach. The context of the notification should 
be clear without an additional service parameter.

Kind regards,
Holger

Holger Dreihahn
European Spacecraft Operations Centre | European Space Agency | S-431
+49 6151 90 2233 | http://www.esa.int/esoc



From:   Wolfgang Hell <Wolfgang_._Hell at t-online.de>
To:     "CCSDS_CSTSWG (css-csts at mailman.ccsds.org)" 
<css-csts at mailman.ccsds.org>, 
Date:   27/02/2015 10:31
Subject:        [Css-csts] URGENT: Discrepancy in the SFW regarding the 
NOTIFY  invocation
Sent by:        css-csts-bounces at mailman.ccsds.org



Dear CSTS colleagues,

While trying to close all RIDs and other comments regarding the SFW, 
John and I detected a discrepancy between some requirements in the main 
part of the SFW document and the NOTIFY invocation type specification in 
annex E. The SFW contained in some place requirements postulating that a 
notification shall report the service that triggered the reported event. 
Taking a look at the type specification, it turns out that this 
information cannot be conveyed except if one would introduce a related 
parameter either by changing the invocation type or by means of 
extension. However, in general the reporting of the service is not 
needed as the user can be safely assumed to know which service is being 
used when the notification comes in. There might be the case that a 
service has to send notifications that actually triggered due to other 
services being used in which case one would need the extra parameter 
identifying the service with which the notification is associated. It 
turns out that not even the MD CSTS has such need. Therefore John and I 
favor the following approach:

- Any requirement postulating that the service triggering an event is 
reported in the notification are removed from the SFW.
- The type specifications associated with the NOTIFY invocation are left 
alone, i.e. no additional parameter is introduced.
- Should at some point in the future the need arise to accommodate an 
additional parameter reporting the service triggering the event, this 
can be achieved by means of extension.

Given that we are proposing to remove an originally specified 
capability, we are seeking the WG consent on this point. A reply at your 
earliest convenience will be appreciated since John and I are trying to 
wrap up the SFW asap.

Best regards,
Wolfgang

_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts


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/20150227/3b861554/attachment.html>