<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle24
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:376005693;
mso-list-type:hybrid;
mso-list-template-ids:-644868520 -106654950 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1
{mso-list-id:577374194;
mso-list-template-ids:358107448;}
@list l1:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2
{mso-list-id:1667515724;
mso-list-template-ids:1996773128;}
@list l2:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3
{mso-list-id:1866553802;
mso-list-template-ids:-523852688;}
@list l3:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">CSTSWG colleagues ---<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Earlier today I had responded to some of Wolfgang’s comments on the
</span><span style="color:#1F4E79">MdCstsProvider FR. After sending the email, I came across a statement in the MD-CSTS Blue Book that has caused me to modify my response with respect to the
</span><span style="font-family:"Courier New";color:#1F4E79">mdProdConfigurationChange</span><span style="color:#1F4E79">
</span><span style="color:#1F497D">event. In my earlier email (below), I said that I had excluded the
</span><span style="font-family:"Courier New";color:#1F4E79">mdProdConfigurationChange</span><span style="color:#1F4E79">
</span><span style="color:#1F497D">event because of the previous interpretation of MD service production, but that the new interpretation justified inclusion of the
</span><span style="font-family:"Courier New";color:#1F4E79">mdProdConfigurationChange</span><span style="color:#1F4E79">
</span><span style="color:#1F497D">event. However, my recollection was faulty, as I discovered after having sent the email. The actual reason for excluding the
</span><span style="font-family:"Courier New";color:#1F4E79">mdProdConfigurationChange</span><span style="color:#1F4E79">
</span><span style="color:#1F497D">event was stated in the last paragraph of section 8.1 of the MD-CSTS book:
<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">“The Monitored Data service supports the
<span style="font-family:"Courier New"">production-status</span> parameter and the production status change event. However, the Monitored Data service does not support the production configuration change event because it is redundant with information that is
already available through the MD service.<span style="color:#1F497D">”<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">The thinking was that since the </span>
<span style="font-family:"Courier New";color:#1F4E79">mdProdConfigurationChange</span><span style="color:#1F4E79">
</span><span style="color:#1F497D">event only indicates that “something” had changed without even identifying the FR instance much less the specific configuration parameter, the assumption was that the user of the MD service would instead use the On-Change-Option
Cyclic Report procedure of the service to monitor the reconfigurable parameters of the monitored FRs, which would identify the exact parameters and FR instances that had changed. If that is still a valid assumption, then there is no need to include the
</span><span style="font-family:"Courier New";color:#1F4E79">mdProdConfigurationChange</span><span style="color:#1F4E79">
</span><span style="color:#1F497D">event. However, if the WG decides that the </span>
<span style="font-family:"Courier New";color:#1F4E79">mdProdConfigurationChange</span><span style="color:#1F4E79">
</span><span style="color:#1F497D">event is desired anyway, it can be added.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><u><span style="color:#1F497D">Unless the WG decides that the
</span></u><u><span style="font-family:"Courier New";color:#1F4E79">mdProdConfigurationChange</span><span style="color:#1F4E79">
</span><span style="color:#1F497D">event should be included even though it provides less information than is available through the MD service procedures, this event will continue to be excluded.<o:p></o:p></span></u></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">John<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> John Pietras <br>
<b>Sent:</b> Monday, November 30, 2020 12:31 PM<br>
<b>To:</b> CCSDS_CSTSWG (css-csts@mailman.ccsds.org) <css-csts@mailman.ccsds.org>; Wolfgang Hell <wo_._he@t-online.de><br>
<b>Subject:</b> Questions regarding absence of mdProdConfigurationChange event and mdSetContrParams directive
<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F4E79">CSTSWG colleagues,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79">In Wolfgang’s review (below) of the updates that I made to “my” Tier-1 FRs, he observed that I had included neither the
</span><span style="font-family:"Courier New";color:#1F4E79">mdProdConfigurationChange</span><span style="color:#1F4E79">
</span><span style="color:#1F497D">event </span><span style="color:#1F4E79">nor the
</span><span style="font-family:"Courier New";color:#1F4E79">mdSetContrParams</span><span style="color:#1F4E79">
</span><span style="color:#1F497D">directive </span><span style="color:#1F4E79">for the MdCstsProvider FR. When we discussed this comment very briefly during last week’s telecon I agreed to revisit the issue. The following paragraphs discus the various issues.
For each of the issues, I have <u>highlighted by underline</u> the direction that I intend to take unless otherwise decided by the WG.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79">First, let me address the absences of the
</span><span style="font-family:"Courier New";color:#1F4E79">mdSetContrParams</span><span style="color:#1F4E79"> directive. As I noted during last week’s brief discussion, the procedures that comprise the MD service (Association Control, On-Change-Option-Cyclic
Report (derived from Cyclic Report), Information Query, and Notification) all have configuration parameters that are static (not dynamically reconfigurable). The configurable parameters of the MdCstsProvider FR consist of these static configuration parameters
PLUS one other configurable parameter – </span><span style="font-family:"Courier New";color:#1F4E79">mdResponseTimeout</span><span style="color:#1F4E79">, which is the service-specific version of the
</span><span style="font-family:"Courier New";color:#1F4E79">response-timeout</span><span style="color:#1F4E79"> parameter mandated for all CSTSes in 3.2.1.2 of (the forthcoming) CSTS SFW B-2. In defining and requiring the presence of the
</span><span style="font-family:"Courier New";color:#1F4E79">response-timeout</span><span style="color:#1F4E79"> parameter, SFW B-2, is mute on the point of whether or not the parameter is dynamically reconfigurable. Because this parameter represents a mutually-agreed
value between service user and service provider about when an abort situation exists, my belief is that this should be a static configuration parameter. If that is the consensus of the WG, then there would be no dynamically-configurable parameters of the MD
service and thus no need for the </span><span style="font-family:"Courier New";color:#1F4E79">mdSetContrParams</span><span style="color:#1F4E79"> directive. If the WG decides that
</span><span style="font-family:"Courier New";color:#1F4E79">response-timeout</span><span style="color:#1F4E79"> parameters such as
</span><span style="font-family:"Courier New";color:#1F4E79">mdResponseTimeout</span><span style="color:#1F4E79"> should be dynamically reconfigurable, then the
</span><span style="font-family:"Courier New";color:#1F4E79">mdSetContrParams</span><span style="color:#1F4E79"> directive would be added with the clarification that it applies only to
</span><span style="font-family:"Courier New";color:#1F4E79">mdResponseTimeout</span><span style="color:#1F4E79">.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p>
<p class="MsoNormal"><u><span style="color:#1F4E79">Unless the WG decides that the response timeouts should be dynamically reconfigurable, I will continue to exclude an
</span></u><u><span style="font-family:"Courier New";color:#1F4E79">mdSetContrParams</span><span style="color:#1F4E79"> directive.<o:p></o:p></span></u></p>
<p class="MsoNormal"><b><span style="color:#1F4E79"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><b><span style="color:#1F4E79">NOTE – it might be worth considering adding an additional sentence, clause, or clarification to 3.2.1.2 of the SFW to reflect the decision regarding the dynamic modifiability of the
</span></b><b><span style="font-family:"Courier New";color:#1F4E79">response-timeout</span><span style="color:#1F4E79"> parameters, e.g., add to the end of 3.2.1.2 the sentence “The value of the
</span></b><b><span style="font-family:"Courier New";color:#1F4E79">response-timeout</span><span style="color:#1F4E79"> parameter shall | shall not be dynamically configurable while the service instance is bound.” When to include this change will depend on
Tom G’s preparation of the SFW for release for CESG polling.<o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79">Now turn our attention to the </span>
<span style="font-family:"Courier New";color:#1F4E79">mdProdConfigurationChange</span><span style="color:#1F4E79"> event. Originally, (and this is the way it is written in the B-1 version of the MD-CSTS book), I had envisioned a Monitored Data Collection FR
to represent the functionality of making the parameter values and events of all FR instances of a Service Package available to the MD service instance. As part of this approach, the production status of the MD service was defined to be strictly and solely
the resource status of the MD Collection FR. The motivation for this definition was, frankly, to avoid having to define what an operational production status would be for the MD service when in a sense the true production comprised all of the FRs in the Service
Package. The MD Collection FR would have no configuration parameters (hence, no need for an
</span><span style="font-family:"Courier New";color:#1F4E79">mdProdConfigurationChange</span><span style="color:#1F4E79"> event)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79">Subsequently, I had difficulty justifying the existence of the MD Collection FR, in particular as something that an ESLT would have to “implement” – there was nothing to configure, and its resource status (its
only reportable parameter) was itself vaguely and circularly defined. So I deleted the MD Collection FR.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79">But that deletion re-raises the question that I had tried to abstract away with the MD Collection FR, namely, what is the production status of the MdCstsProvider FR? We not only have address this for the FR definition
in the Tier-1 FR SANA registry but also in the upcoming revision of the MD book itself.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79">My current thinking is to treat the production status of the MD service instance as essentially the status of the Service Package as a whole:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79">Configured – </span><span style="font-family:"Courier New";color:#1F4E79">mdProdStat
</span><span style="color:#1F4E79">has the value ‘configured’ when qualified parameters can be generated and event notifications can be emitted for the functional resources that comprise the Service Package. NOTE -The intention of defining “configured” this
way is to give the ESLT implementation flexibility in defining when the individual actual resources transition among unconfigured to configured to configured. If the MD service instance is able to report something for every FR in the Service Package, even
if that something is ‘unavailable’, then the Service Package – and therefore </span>
<span style="font-family:"Courier New";color:#1F4E79">mdProdStat</span><span style="color:#1F4E79"> - is considered to be configured.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79">Operational - </span><span style="font-family:"Courier New";color:#1F4E79">mdProdStat</span><span style="color:#1F4E79"> has the value ‘operational’ when the functional resources of the Service Package that are
needed to be operational at that given time are all operational. NOTE - The “at that given time” phrase allows the provider the flexibility to, for instance, internally transition resources that aren’t needed at the beginning of the execution of the Service
Package from configured to operational later in the execution of the Service Package on a just-in-time basis.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79">Halted - </span><span style="font-family:"Courier New";color:#1F4E79">mdProdStat
</span><span style="color:#1F4E79">has the value ‘halted’ when one or more of the functional resources of the Service Package that should be operational at that given time has been halted.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79">Interrupted - </span><span style="font-family:"Courier New";color:#1F4E79">mdProdStat
</span><span style="color:#1F4E79">has the value ‘interrupted’ when one or more of the functional resources of the Service Package that should be operational at that given time has been interrupted.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p>
<p class="MsoNormal"><u><span style="color:#1F4E79">If these interpretations of MD production status acceptable to the WG, I will reflect them in the MdCstsProvider definition in the Tier-1 data set and in Issue-2 of the MD book.<o:p></o:p></span></u></p>
<p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p>
<p class="MsoNormal"><s><span style="color:#1F4E79">Now, finally, this change in the interpretation of MD production has the corollary reinterpretation of the
</span></s><s><span style="font-family:"Courier New";color:#1F4E79">mdProdConfigurationChange</span><span style="color:#1F4E79"> event, in which the change of any configuration parameter in any functional resource instance in the Service Package triggers the
event. <o:p></o:p></span></s></p>
<p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p>
<p class="MsoNormal"><s><u><span style="color:#1F4E79">I will therefore include the
</span></u></s><s><u><span style="font-family:"Courier New";color:#1F4E79">mdProdConfigurationChange</span><span style="color:#1F4E79"> event in the MdCstsProvider definition in the Tier-1 data set, defined as above.<o:p></o:p></span></u></s></p>
<p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p>
<p class="MsoNormal"><s><span style="color:#1F4E79">NOTE that there is still some ambiguity here:
<o:p></o:p></span></s></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><![if !supportLists]><s><span style="color:#1F4E79"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span></s><![endif]><s><span style="color:#1F4E79">Should the event be emitted if any of the FRs in the whole Service Package has a parameter change, regardless of whether the FR being changed is operational at the time, or supposed to be operational
at the time?, or <o:p></o:p></span></s></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><![if !supportLists]><s><span style="color:#1F4E79"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span></s><![endif]><s><span style="color:#1F4E79">Should the event notifications occur only for configuration changes in FRs that should be operational at the given time?
<o:p></o:p></span></s></p>
<p class="MsoNormal"><s><span style="color:#1F4E79">I think that we can leave this detail to the individual implementations, but if anyone has any strong feelings one way or another it would be appropriate to raise them now.<o:p></o:p></span></s></p>
<p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79">I look forward to your comments.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79">John<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Wolfgang Hell [<a href="mailto:wo_._he@t-online.de">mailto:wo_._he@t-online.de</a>]
<br>
<b>Sent:</b> Wednesday, November 25, 2020 5:06 AM<br>
<b>To:</b> John Pietras <<a href="mailto:john.pietras@gst.com">john.pietras@gst.com</a>>;
<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a><br>
<b>Subject:</b> Re: Tier 1 frm file with my updates<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>Dear John,<span style="font-size:12.0pt"><o:p></o:p></span></p>
<p>Thank you for the updates. Please find some comments <span style="color:red">in red font</span> inserted into your original message.<o:p></o:p></p>
<p>Best regards,<o:p></o:p></p>
<p>Wolfgang<o:p></o:p></p>
<p><o:p> </o:p></p>
<div>
<p class="MsoNormal">Am 23.11.2020 um 18:46 schrieb John Pietras:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoPlainText">Dear Holger and Wolfgang,<o:p></o:p></p>
<p class="MsoPlainText">I have updated "my" FRs in the attached file in accordance with the decision made in the WG. I used as the base for my changes the file that Wolfgang sent on 10 November. But before I summarize the changes that I made, I would like to
thank Wolfgang for adding the new OperatorNotify event to all of the FRs - I was expecting to have to update "my" FRs.<o:p></o:p></p>
<p class="MsoPlainText">So here are the changes that I have made:<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-indent:-.25in;mso-list:l3 level1 lfo4">
<![if !supportLists]><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>OfflineFrameBuffer<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.75in;text-indent:-.25in;mso-list:l2 level1 lfo6">
<![if !supportLists]><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>Changed the OfflineFrameBufferRetentionPolicy parameter choice from ‘never’ to ‘storageLimited’
<span style="color:red">WH: Because of the CHOICE, in case of never, no engineering unit applies, while in case of timeLimited the engineering unit is hour. In such case I filled in the Engineering Unit field with "N/A / hour". I'm not sating that one has to
do it that way - I can also live with leaving the Engineering Unit field blank. But a uniform approach would be nice. Also, to make the ASN.1 as informative as possible, I suggest to add a comment to the timeLimited element specifying the applicable engineering
unit. Perhaps I'm overly ambitious by always trying to specify a value range constraint that looks realistic for the specific parameter. LongIntPos is certainly more than ever needed.
</span><o:p></o:p></p>
<p class="MsoPlainText" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.75in;text-indent:-.25in;mso-list:l2 level1 lfo6">
<![if !supportLists]><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>Deleted the PurgePriority, PurgeCessationThreshold, PurgeWarningThreshold parameters and PurgeWarningEvent event, as we decided that they were overkill<br>
<br>
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-indent:-.25in;mso-list:l3 level1 lfo4">
<![if !supportLists]><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>TdmRecordingBuffer – deleted the RetentionPolicy parameter as overkill (it will simply be FIFO)<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-indent:-.25in;mso-list:l3 level1 lfo4">
<![if !supportLists]><span style="mso-list:Ignore">3.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>MdCstsProvider <span style="color:red">WH: It occurs to me that the event mdProdConfigurationChange is missing as well as the directive mdSetContrParams.</span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo8">
<![if !supportLists]><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>Changed ddSvcProductionStatus to tdProdStat <span style="color:red">
WH: I can see that you have applied the necessary changes, but apparently you did not run the "Create ASN.1 / XSD types" function. Therefore the Type Definition in the Property view has not been updated and still shows the obsolete type definition MdSvcProductionStatus
::= SvcProductionStatusVersion1. This also affects the other changes listed below, where Md and Td got mixed up.</span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo8">
<![if !supportLists]><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>Changed type of TdProdStat to ProdStat (was ProdStatV1), no longer external OID for the type<o:p></o:p></p>
<p class="MsoListParagraph" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo8">
<![if !supportLists]><span style="mso-list:Ignore">3.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>TdProdConfigurationChangeEvtValue type has been changed to ProdConfigurationChangeEventValue, which is defined in the Module as ‘NULL’) (TdProdConfigurationChangeEvtValue had previously been cast directly as ‘NULL’).<br>
<br>
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-indent:-.25in;mso-list:l3 level1 lfo4">
<![if !supportLists]><span style="mso-list:Ignore">4.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>TdCstsProvider – same changes as for MdCstsProvider<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">In moving the MD and TD FRs to SFW V2, we can delete the ProdStatV1 type from the Module, but I did not do that. In the past there were problems with the cross-references when things were changed in the Module. I think that Holger fixed
that, but I wasn’t sure. If it is okay to delete that type, Holger, would you please do it? Thanks.
<span style="color:red">WH: On that occasion we shall also remove the no longer needed import of the types from an external ASN.1 module.</span><o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">Best regards,<o:p></o:p></p>
<p class="MsoPlainText">John<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">-----Original Message-----<br>
From: Wolfgang Hell [<a href="mailto:wo_._he@t-online.de">mailto:wo_._he@t-online.de</a>]
<br>
Sent: Tuesday, November 10, 2020 3:54 AM<br>
To: <a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>; John Pietras
<a href="mailto:john.pietras@gst.com"><john.pietras@gst.com></a><br>
Subject: Tier 1 frm file updated as per our "Three-way" discussion<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">Dear Holger and John,<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">As agreed in yesterday's telecon I have updated the Tier 1 frm file in accordance with the outcome of our discussion. We concluded that in the context of CCSDS 401 there is no need to explicitly reference the FR instance generating the
forward carrier. However, given that spacecraft may have more than one forward link typically each of them operating in a different frequency band, one should know to which of the forward links the return signal is coherent. This could be indicated by simply
stating the frequency band of the "coherency" forward link. <o:p></o:p></p>
<p class="MsoPlainText">Alternatively one can express this by means of the transponder ratio.
<o:p></o:p></p>
<p class="MsoPlainText">This option has the advantage that this covers also multi-spacecraft arrangements where those spacecraft share the same forward physical channel, but use different SCIDS or VCID sets or APID sets. In order to get separate return physical
channels in the same frequency band, one can use non-standard transponder ratios. Therefore the transponder ratio parameter shall permit the specification of non-CCSDS transponder ratios. At this point we cannot exclude that in the context of CCSDS 415 a different
mechanism will be necessary for identifying the forward link to which the given return link is coherent. We agreed that we will work that out when the CCSDS 415 related FR types will be specified, but we will not worry about it in the context of the Tier 1
and Tier 2 FRM delivery.<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">Please find attached the Tier 1 frm file modified as outlined above.<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">Best regards,<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">Wolfgang<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
</blockquote>
</div>
</body>
</html>