[Css-csts] Range of delivery cycle values

[Margherita.di.Giulio at esa.int]

Dear John, 
I am in favour of the most flexible solution, the one with the simple type 
specification ?IntPos? in the ASN.1. 
So, this would be the "type" of the new configuration parameter that 
Wolfgang agreed to add to the Framework. 

A Service using the Framework may/can still delimit the lower/upper values 
for such parameter, depending on  service-specific constraints.

Kind regards,
Margherita


----------------------------------------------------------------
Margherita di Giulio
Ground Station Back-end Section (HSO-GIB)
European Space Agency ESA/ESOC
Robert-Bosch-Str. 5
D-64293 Darmstadt - Germany
Tel: +49-6151-902779
e-mail: Margherita.di.Giulio at esa.int





From:   John Pietras <john.pietras at gst.com>
To:     "CCSDS_CSTSWG (css-csts at mailman.ccsds.org)" 
<css-csts at mailman.ccsds.org>, 
Date:   25/11/2014 20:05
Subject:        [Css-csts] Range of delivery cycle values
Sent by:        css-csts-bounces at mailman.ccsds.org



CSTSWG colleagues ---
I am in the process of updating the status and disposition of the RIDs 
that were submitted against the Monitored Data CSTS Red-1 book. One of 
those RIDs, NASA-4, Min/max values for delivery cycle, asks what an 
implementation should do if the delivery cycle requested in the Cyclic 
Report START invocation cannot be supported by that implementation. The 
CSTS SFW specifies a range of 1 second to 600 seconds (10 minutes), which 
is enforced by the ASN.1 (that is, if anything greater than 600 is 
submitted, it will cause a protocol abort). 
 
In our discussion of this RID at the London meeting, we decided to make 
the allowed delivery cycle range a configuration parameter, such that the 
if a START invocation contains a delivery-cycle value that is within the 
range supported by the ASN.1 type specification but outside the range 
permitted by the configuration parameter, the invocation will be rejected 
with the diagnostic ?out of range?. Wolfgang agreed to add an appropriate 
configuration parameter to the Framework Cyclic Report procedure.
 
I also seem to recall us discussing whether it makes sense for the Cyclic 
Report procedure to put a hard upper limit (currently 600) on the number 
of seconds allowed between reports. If a user wants reports only every 15 
minutes, why should any  implementation be prohibited from providing 
less-frequent reports? My recollection is that we decided to remove the 
upper bound, but my notes from the meeting do not mention this part of the 
discussion. 
 
So my questions are:
a)      Did we indeed decide to change the delivery cyclic ?range? allowed 
by the Cyclic Report procedure to be anything from one second and up? That 
would mean that the specification of the type for deliveryCycle would 
change from ?INTEGER (1..600)? to simply ?IntPos? in the ASN.1.
b)      Would the associated configuration cover only the lower bound on 
allowed delivery cycle values (e.g., at most every 2 seconds even though 
the Framework supports once every second), or would it also allow an upper 
bound to be set (even though, if (a) is correct, the procedure itself does 
not have an upper bound)? In effect, will there be one configuration 
parameter, minimumAllowedDeliveryCycle, or also a second configuration 
parameter maximumAllowedDeliveryCycle (or perhaps a complex configuration 
parameter that contains both the minimum and maximum allowed values)?
 
Thanks.
 
Best regards,
John 
 _______________________________________________
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/20141203/45ebd0dd/attachment.html>