[Css-csts] RE: MD-CSTS "RIDs" resulting from Guidelines comparison - part 2

[Yves.Doat at esa.int]

Dear John,

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.

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?

On your point 4, we agreed that 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.

Best regards

Yves
__________________________________________________
Head of the Ground Facilities Infrastructure Section  (HSO-ONI) 
in the Ground Facilities Operations Division
ESA/ESOC Robert-Bosch Strasse 5
D-64293 Darmstadt, Germany
Tel.: +49 (6151) 90.2288               Fax:+49 (6151) 90.3046
Internet: http://www.esa.int/
__________________________________________________




From:   John Pietras <john.pietras at gst.com>
To:     "Yves.Doat at esa.int" <Yves.Doat at esa.int>
Cc:     "CCSDS_CSTSWG \(css-csts at mailman.ccsds.org\)" 
<css-csts at mailman.ccsds.org>
Date:   24/11/2014 23:37
Subject:        [Css-csts] RE: MD-CSTS "RIDs" resulting from Guidelines 
comparison      - part 2
Sent by:        css-csts-bounces at mailman.ccsds.org



Dear Yves,
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. 
 
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. 

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.

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).

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.?

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.
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.
 
Best regards,
John 
 _______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts


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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20150201/08fb0c46/attachment.html>