<font size=2 face="sans-serif">Dear John,</font>
<br>
<br><font size=2 face="sans-serif">On your point 3, I fully agree with
you. What is defined in the Framework is available and should not be required
to be imported into the new service.</font>
<br>
<br><font size=2 face="sans-serif">You propose to add a new section (I
assume it corresponds to the section 7 of the TD Service) will be a new
section 4.8 of the Guidelines. your proposal looks Ok to me. I understand
you will prepare the text for insertion. Is that correct?</font>
<br>
<br><font size=2 face="sans-serif">On your point 4, we agreed that </font><font size=3 face="Times New Roman">the
import would only be required if the OID of the original procedure would
be reused to build a new OID. Considering this answer, I do not see an
impact on the guidelines.</font>
<br>
<br><font size=3 face="Times New Roman">Best regards</font>
<br>
<br><font size=2 face="sans-serif">Yves<br>
__________________________________________________<br>
Head of the Ground Facilities Infrastructure Section  (HSO-ONI) <br>
in the Ground Facilities Operations Division<br>
ESA/ESOC Robert-Bosch Strasse 5<br>
D-64293 Darmstadt, Germany<br>
Tel.: +49 (6151) 90.2288              
Fax:+49 (6151) 90.3046<br>
Internet: </font><a href=http://www.esa.int/><font size=2 face="sans-serif">http://www.esa.int/</font></a><font size=2 face="sans-serif"><br>
__________________________________________________<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">John Pietras <john.pietras@gst.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">"Yves.Doat@esa.int"
<Yves.Doat@esa.int></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:      
 </font><font size=1 face="sans-serif">"CCSDS_CSTSWG
\(css-csts@mailman.ccsds.org\)" <css-csts@mailman.ccsds.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">24/11/2014 23:37</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">[Css-csts] RE:
MD-CSTS "RIDs" resulting from Guidelines comparison    
   - part 2</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:    
   </font><font size=1 face="sans-serif">css-csts-bounces@mailman.ccsds.org</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3 face="Calibri">Dear Yves,</font>
<br><font size=3 face="Calibri">Here is the completion of my attempt to
address the issues that were raised by you after your analysis of the MD-CSTS
vis-à-vis the Guidelines. Since my previous email (part 1) listed 2 topics,
this note picks up with topic #3. </font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">3.    In my review of the previous
version of the Guidelines, I had asked if the Imported Identifiers module
(see section 4.10.4 of the Guidelines) should also import the procedure
identifiers of the procedure identifiers that are directly adopted or refined-only.
Under section 10.4.6 of the Guidelines, I asked a similar question – should
the new service’s object identifier module annex specify the procedures
that the service directly adopts or simply refines. Your response to both
questions was that the import would only be required if the original procedure
or procedure ID  would be reused to build a new OID, and that we do
not need to import the SFW procedure IDs otherwise. I concur with that
response.  <br>
<br>
Taking that logic one step further, it should not be necessary to import
in the service’s object identifier module annex any service-generic parameter
OIDs (as defined in E3.17 of the CSTS SFW) or the OIDs of parameters, events,
or directives that belong to the Framework procedures used by the service
(as defined in E3.16 of the CSTS SFW). The assumption should be that all
service-generic parameters and  parameters, events, or directives
that belong to the Framework procedures used by the service are automatically
included in the service, and can only be excluded by explicitly excluding
them. At the London meeting, the WG agreed that any refinements of the
definitions of the service-generic parameters would be documented in a
separate section, as has been done in the version of the TD-CSTS that was
posted to the CWE before the London meeting. I propose that we generalize
this new section to also include refinement of the definition of any framework
procedure parameter, event, or directive, and to also include the exclusion
of any service-generic parameter or any framework procedure parameter,
event, or directive. To the degree that such refinements and/or exclusions
will not take place, the new section will only rarely be needed. If the
WG agrees to this approach, I offer to try to generate some text for the
Guidelines.<br>
<br>
In the spirit of not needing to add the OIDs for the service-generic parameters
and framework procedure parameters, events, and directives to a service’s
object identifier module annex, I have deleted the import of those parameters
from the MD-CSTS Service Object Identifier Module (annex B).<br>
</font>
<div><font size=3 face="Calibri">4.    I had asked another question
on the Guidelines’ Service Procedure Identifiers section (4.10.6). I asked
“Since the procedure IDs are used only in the context of the service,
is it necessary to register them with SANA?”, to which you responded “In
principle this is not required. I personally find a good practice to centralize
the registration with SANA so that one can get a clear view of the OID.
The WG should decide.”<br>
<br>
As you know, I was not in the meeting when the Guidelines document was
discussed. Was this question brought up, and did the WG make a decision?
The answer to this question does not affect the MD-CSTS (because the MD-CSTS
does not extend any procedures), but I thought I would ask the question
since it was identified in the comments as something the WG would have
to decide on.</font>
<p><font size=3 face="Calibri">I believe that this concludes the list of
questions and issues that you raised regarding the Guidelines as they apply
to the MD-CSTS. I look forward to your responses.</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="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></div><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>