[Css-csts] Range of delivery cycle values

[Wolfgang Hell]

Dear CSTS WG Members,

I concur with outcome of the discussion of this topic and as agreed at 
the London meeting I will add in the SFW a new configuration parameter 
of the Cyclic Report procedure that specifies the minimum reporting 
cycle permitted. For consistency with a change agreed by the WG for the 
latest variant of the SLE Books and different from what Margherita in 
the email below, I suggest NOT to introduce a configuration parameter 
that would allow to limit the maximum reporting cycle. I saw some 
statements that there won't be be an upper bound of the reporting cycle. 
While this is true for values that have any bearing in practice, it is 
not correct in terms of the ASN.1 type specification. Since the 
reporting cycle parameter will be mapped to the IntPos type, it inherits 
the maximum value that type supports.

Please let me know if not introducing a configuration parameter for the 
maximum reporting cycle is acceptable to you.

Best regards,
Wolfgang


Am 03.12.2014 15:29, schrieb 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.
>
>
> _______________________________________________
> Css-csts mailing list
> Css-csts at mailman.ccsds.org
> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20141209/cdeb1f76/attachment.html>