[Css-csts] Range of delivery cycle values

[John Pietras]

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

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