[Css-csts] Range of delivery cycle values

Fri Dec 5 20:33:39 UTC 2014

Dear Margherita,
Thank you for your response. For the sake of moving the MD-CSTS book along, I am going to assume that the CSTS SFW will:

a)      change the type of deliveryCycle from "INTEGER (1..600)" to simply "IntPos" in the ASN.1

b)      define two new configuration parameters for the Cyclic Report procedure: minimum-delivery-cycleycle (the minimum value [in seconds] that deliveryCycle is allowed to have[minimum 1 second]) and maximum-delivery-cycle (the maximum value [in seconds] that deliveryCycle is allowed to have). It will be very easy to change these in the MD-CSTS if the WG decides to do so.

For the purposes of the MD-CSTS, I'm going to make these managed parameters and add a note that says that these are expected to be set based on the capabilities of the service provider's implementation, and therefore they will be specified in the Service Agreement.

Best regards,
John

From: Margherita.di.Giulio at esa.int [mailto:Margherita.di.Giulio at esa.int]
Sent: Wednesday, December 03, 2014 9:29 AM
To: John Pietras
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org); css-csts-bounces at mailman.ccsds.org
Subject: Re: [Css-csts] Range of delivery cycle values

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<mailto:Margherita.di.Giulio at esa.int>

From:        John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>
To:        "CCSDS_CSTSWG (css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>)" <css-csts at mailman.ccsds.org<mailto: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<mailto: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<mailto: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.

________________________________
NOTE: This message was trained as non-spam. If this is wrong, please correct the training as soon as possible.
Spam<https://filter.gst.com/canit/b.php?i=01Nn2toOQ&m=929acfce114e&c=s>
Not spam<https://filter.gst.com/canit/b.php?i=01Nn2toOQ&m=929acfce114e&c=n>
Forget previous vote<https://filter.gst.com/canit/b.php?i=01Nn2toOQ&m=929acfce114e&c=f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20141205/a419f679/attachment.html>