<font size=2 face="sans-serif">Hi Erik,</font>
<br><font size=2 face="sans-serif">For the business of the initiator identifier
and responder identifier we noted yesterday the following:</font>
<br>
<br><font size=2 face="sans-serif"><i>The WG agrees that initiator ID,
responder ID and responder port ID are in the FR model. Wolfgang will add
them for SLE. A comment will be added in the semantic definition. John
will use that approach as well.</i></font>
<p><font size=2 face="sans-serif"><i>The decision if these parameters (like
all parameters) are used for a particular MD SI configuration within a
service agreement / configuration profiles is left to Service Management.</i></font>
<p>
<br><font size=2 face="sans-serif">So the FRM will be complete and CSSM
will take care when they are used. I think this should address your point
and to me it feels right to go that way.</font>
<br>
<br><font size=2 face="sans-serif">Best regards,</font>
<br><font size=2 face="sans-serif">Holger</font>
<br>
<br><font size=2 face="sans-serif">Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | S-431<br>
+49 6151 90 2233 | </font><a href=http://www.esa.int/esoc><font size=2 face="sans-serif">http://www.esa.int/esoc</font></a>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Barkley, Erik
J\(US 3970\) via CSS-CSTS" <css-csts@mailman.ccsds.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"EXTERNAL-Pietras,
John V (US 332C-Affiliate)" <john.pietras@gst.com>, "CCSDS_CSTSWG
(css-csts@mailman.ccsds.org)" <css-csts@mailman.ccsds.org>,
"Wolfgang Hell" <wo_._he@t-online.de></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">"CCSDS Service
Mgmt WG" <smwg@mailman.ccsds.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">05/12/2019 23:09</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [Css-csts]
Issue regarding initiator-identifier and responder-identifier</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">"CSS-CSTS"
<css-csts-bounces@mailman.ccsds.org></font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3 color=#004080 face="Georgia">John et al,</font>
<br><font size=3 color=#004080 face="Georgia"> </font>
<br><font size=3 color=#004080 face="Georgia">I think this is one of the
issues that needs to be coordinated at the area level. As you have
noted via your reference to the technote, the CSSM WG intends to essentially
base the detailed content of the configuration profile on the parameters
stated in the FRM. It seems to me that it will be a substantially non-trivial
enough job to pull off without having to resort to yet another mechanism
other than FRs for stating the various initiator and responder identifiers.
I can appreciate the sensitive info/security concerns, but I think
having the complete model is also important. From the CSSM perspective,
it may in fact be more secure if this information is carried in the service
package – SPDF book -- (via modified result data set) such that you could
in effect have “rolling” identifiers specific for instances that change
tracking-pass to tracking-pass (assuming that the SP is itself encrypted
signed and/or block-chained, etc). I think this might need a broader
discussion and so I am also copying the CSSM WG for cognizance. Unfortunately
I was not able to attend the CSTS WG telecon scheduled for earlier today
so perhaps this is overcome by events but I just wanted to see if we might
come to a broader consensus -- I tend to agree with your approach 3.</font>
<br><font size=3 color=#004080 face="Georgia"> </font>
<br><font size=3 color=#004080 face="Georgia">Best regards,</font>
<br><font size=3 color=#004080 face="Georgia">-Erik </font>
<br><font size=3 color=#004080 face="Georgia"> </font>
<br><font size=3 face="Calibri"><b>From:</b> CSS-CSTS <css-csts-bounces@mailman.ccsds.org>
<b>On Behalf Of </b>John Pietras<b><br>
Sent:</b> Tuesday, December 3, 2019 08:10<b><br>
To:</b> CCSDS_CSTSWG (css-csts@mailman.ccsds.org) <css-csts@mailman.ccsds.org>;
Wolfgang Hell <wo_._he@t-online.de><b><br>
Subject:</b> [EXTERNAL] [Css-csts] Issue regarding initiator-identifier
and responder-identifier</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">CSTSWG colleagues ---</font>
<br><font size=3 face="Calibri">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.</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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. </font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">Off the top of my head, I can think of
several ways that we might remedy this problem:</font>
<ol>
<li value=1><font size=3 face="Calibri">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).</font>
<li value=2><font size=3 face="Calibri">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).</font>
<li value=3><font size=3 face="Calibri">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.</font></ol><font size=3 face="Calibri">My
preference would be for something along the lines of options 2 or 3. </font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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 </font><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"><font size=3 color=#0082bf face="Calibri"><u>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</u></font></a><font size=3 face="Calibri">)</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">I don’t know if we’ll have time to discuss
this on Thursday but we do need to resolve these issues.</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">Best regards,</font>
<br><font size=3 face="Calibri">John</font>
<br><font size=3 face="Calibri"> </font><tt><font size=2>_______________________________________________<br>
CSS-CSTS mailing list<br>
CSS-CSTS@mailman.ccsds.org<br>
</font></tt><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts"><tt><font size=2>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br>
<PRE>This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@esa.int).
</PRE>