<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Dear CSTS WG Members,<br>
      <br>
      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.<br>
      <br>
      Please let me know if not introducing a configuration parameter
      for the maximum reporting cycle is acceptable to you.<br>
      <br>
      Best regards,<br>
      Wolfgang<br>
      <br>
      <br>
      Am 03.12.2014 15:29, schrieb <a class="moz-txt-link-abbreviated" href="mailto:Margherita.di.Giulio@esa.int">Margherita.di.Giulio@esa.int</a>:<br>
    </div>
    <blockquote
cite="mid:14869_1417616959_547F1E3F_14869_7124_1_OF2DD08F3C.AE604E49-ONC1257DA3.003E3DA5-C1257DA3.004F90A5@esa.int"
      type="cite"><font face="Calibri" size="2">Dear John, </font>
      <br>
      <font face="Calibri" size="2">I am in favour of the most flexible
        solution,
        the one with the simple type specification “IntPos” in the
        ASN.1. </font>
      <br>
      <font face="Calibri" size="2">So, this would be the "type"
        of the new configuration parameter that Wolfgang agreed to add
        to the Framework.
         </font>
      <br>
      <br>
      <font face="Calibri" size="2">A Service using the Framework
        may/can still
        delimit the lower/upper values for such parameter, depending on
         service-specific
        constraints.</font>
      <br>
      <br>
      <font face="Calibri" size="2">Kind regards,<br>
        Margherita</font>
      <br>
      <br>
      <br>
      <font face="Calibri" size="2">----------------------------------------------------------------<br>
        Margherita di Giulio<br>
        Ground Station Back-end Section (HSO-GIB)<br>
        European Space Agency ESA/ESOC<br>
        Robert-Bosch-Str. 5<br>
        D-64293 Darmstadt - Germany<br>
        Tel: +49-6151-902779<br>
        e-mail: <a class="moz-txt-link-abbreviated" href="mailto:Margherita.di.Giulio@esa.int">Margherita.di.Giulio@esa.int</a><br>
      </font><font face="sans-serif" size="2"><br>
      </font>
      <br>
      <br>
      <br>
      <br>
      <font color="#5f5f5f" face="sans-serif" size="1">From:      
         </font><font face="sans-serif" size="1">John Pietras
        <a class="moz-txt-link-rfc2396E" href="mailto:john.pietras@gst.com"><john.pietras@gst.com></a></font>
      <br>
      <font color="#5f5f5f" face="sans-serif" size="1">To:      
         </font><font face="sans-serif" size="1">"CCSDS_CSTSWG
        (<a class="moz-txt-link-abbreviated" href="mailto:css-csts@mailman.ccsds.org">css-csts@mailman.ccsds.org</a>)"
        <a class="moz-txt-link-rfc2396E" href="mailto:css-csts@mailman.ccsds.org"><css-csts@mailman.ccsds.org></a>,
      </font>
      <br>
      <font color="#5f5f5f" face="sans-serif" size="1">Date:      
         </font><font face="sans-serif" size="1">25/11/2014 20:05</font>
      <br>
      <font color="#5f5f5f" face="sans-serif" size="1">Subject:    
           </font><font face="sans-serif" size="1">[Css-csts] Range
        of delivery cycle values</font>
      <br>
      <font color="#5f5f5f" face="sans-serif" size="1">Sent by:    
           </font><font face="sans-serif" size="1"><a class="moz-txt-link-abbreviated" href="mailto:css-csts-bounces@mailman.ccsds.org">css-csts-bounces@mailman.ccsds.org</a></font>
      <br>
      <hr noshade="noshade">
      <br>
      <br>
      <br>
      <font face="Calibri" size="2">CSTSWG colleagues ---</font>
      <br>
      <font face="Calibri" size="2">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). </font>
      <br>
      <font face="Calibri" size="2"> </font>
      <br>
      <font face="Calibri" size="2">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.</font>
      <br>
      <font face="Calibri" size="2"> </font>
      <br>
      <font face="Calibri" size="2">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. </font>
      <br>
      <font face="Calibri" size="2"> </font>
      <br>
      <font face="Calibri" size="2">So my questions are:</font>
      <br>
      <font face="Calibri" size="2">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.</font>
      <br>
      <font face="Calibri" size="2">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)?</font>
      <br>
      <font face="Calibri" size="2"> </font>
      <br>
      <font face="Calibri" size="2">Thanks.</font>
      <br>
      <font face="Calibri" size="2"> </font>
      <br>
      <font face="Calibri" size="2">Best regards,</font>
      <br>
      <font face="Calibri" size="2">John </font>
      <br>
      <font face="Calibri" size="2"> </font><tt><font size="2">_______________________________________________<br>
          Css-csts mailing list<br>
          <a class="moz-txt-link-abbreviated" href="mailto:Css-csts@mailman.ccsds.org">Css-csts@mailman.ccsds.org</a><br>
        </font></tt><a moz-do-not-send="true"
        href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts"><tt><font
            size="2">http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts</font></tt></a><tt><font
          size="2"><br>
        </font></tt>
      <br>
      <pre>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.
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Css-csts mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Css-csts@mailman.ccsds.org">Css-csts@mailman.ccsds.org</a>
<a class="moz-txt-link-freetext" href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts">http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>