<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=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:0 0 0 0 0 0 0 0 0 0;}
@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.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;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@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:450251692;
mso-list-type:hybrid;
mso-list-template-ids:1658739724 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
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">CSTSWG colleagues ---<o:p></o:p></p>
<p class="MsoNormal">Recently (perhaps in Darmstadt?) Wolfgang and I discussed whether the initiator-identifier and responder-identifier parameters of the Association Control procedure should be in the list of configuration parameters for a(n) SLE/CS Transfer
Service Provider FR. I had envisioned including them but Wolfgang has excluded them from his SLE TS Provider FRs (FCLTU, RAF, etc.). When we discussed it he stated his belief that they should not be in the FR definition because that is sensitive information
that should not be accessible by, for instance, MD-CSTS. Rather, Wolfgang argued, this information should be exchanged by some “other” (not specified by CCSDS) means. Conceptually, this other mechanism would contain these identifiers in a table that has as
a key into it the service-instance-identifier, which *<b>is</b>* in the FR definition. In particular Wolfgang said that he did not think that these parameters should be included in the configuration profiles that would be used for scheduling Service Packages.
Wolfgang’s argument made sense to me and I agreed with his logic, and planned to remove those parameters from the CSTS Provider FRs for which I am responsible – Forward Frame, Monitored Data, and Tracking Data.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">HOWEVER, I now realize that the FF, MD, and TD books *<b>all</b>* identify these two parameters as “service management” parameters and assign them their service-specific classifiers. The assignment of the classifiers implies that these
are to be registered as configuration parameters of the respective FRs, and there is *<b>no</b>* indication in any of the documentation that they are to be treated in a special manner – i.e., be excluded from the definition of the FRs that are registered in
SANA. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Off the top of my head, I can think of several ways that we might remedy this problem:<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>Somehow redefine them as some sort of “special” configuration parameters (nor “normal” service management parameters) in the FF, TD, and MD service specifications. E.g., no classifiers would be specified. This would involve tweaking
the FF book (relatively easy), TD book (a bit harder since it’s already been submitted to the Secretariat) and the MD book (involves a TC since it has already been published).<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>Leave them as configuration parameters of the FRs and add them to the SANA Registry FR definitions, but include caveats on their definitions that recommend that they not be included in configuration profile and GET-able only under highly
secure circumstances. This approach (a) has no impact on the CSTS books and (b) allows whatever mechanisms that *<b>are</b>* used to leverage the existing information architecture – e.g., a privileged, secure instance of MD-CSTS could be implemented that would
be permitted to read these values (e.g., to confirm their real-time setting if the service user is having problems binding).<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="mso-list:Ignore">3.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>Similar to option 2, leave them as configuration parameters of the FRs and add them to the SANA Registry FR definitions, but let the SMWG decide on and enforce the restrictions in the Configuration Profile specification, and let the
Agencies/Providers decide who can read these parameters.<o:p></o:p></p>
<p class="MsoNormal">My preference would be for something along the lines of options 2 or 3.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In a somewhat related topic, there is also the responder-port-id parameter that is specified in the existing CSTS specifications as a service management parameter. Whatever we decide to do about the initiator-identifier and responder-identifier
parameters, we need to include the responder-port-id parameter as a parameter of FR because it *<b>does</b>* need to be in the configuration profiles in order to support the dynamic allocation method of TCP Socket scheduling that the SMWG wants to support
(see section 3.4.2 of <a href="https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Tech%20Note%20Development/Config%20Profile%20Svc%20Agreement%20Tech%20Note/Simplified%20ConfigProfilesAndSvcAgreements_TechNote-v1x4-clean.docx?Web=1">
https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Tech%20Note%20Development/Config%20Profile%20Svc%20Agreement%20Tech%20Note/Simplified%20ConfigProfilesAndSvcAgreements_TechNote-v1x4-clean.docx?Web=1</a>)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I don’t know if we’ll have time to discuss this on Thursday but we do need to resolve these issues.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
<p class="MsoNormal">John<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>