1. Cross Support Transfer Services - Tracking Data Service 0.10 (in progress) 23-27 March 2015 London, United Kingdom John Pietras Global Science and Technology, Inc, Greenbelt, MD, USA

2. www.ccsds.org Outstanding Issues/ Required Cleanup (1 of 3) 2  When a procedure is derived from an SFW procedure, that procedure gets a new name and unique Procedure Type. Parameter Names of configuration parameters inherited from the parent SFW procedure must be named using the Parameter Type registered under the parent procedure  A NOTE to this effect has been added to address the case as it applies specifically to the TD-CSTS (under 4.6.1), but it is general to all derived services  Is this addressed in the CSTS SFW and/or Guidelines?  DECISION – This will be described in the SFW, so the NOTE will be deleted from the TD-CSTS

3. www.ccsds.org 3 Outstanding Issues/ Required Cleanup (2 of 3)  WH suggested making the BTDMD configuration parameter tracking-data-types accessible (it currently is not)  pBTDMDtrackingDataTypes OID is registered as {trackingDataServiceExtServiceParameters 1} in the OID annex Is this correct?  Value must be formatted as a qualified parameter in order for the GET to return it PBTDMDtrackingDataTypes ::= SET OF TrackingDataType TrackingDataType ::= Enumerated { dopplerInstantaneous [0], dopplerIntegrated [1] etc. Enumerated ::= intUnsigned Enumerated type is currently declared for TD-CSTS, but it should be a Framework type DECISION: Enumerated type will be defined in the SFW  Currently, the Configuration Parameters section of the BTDMD procedure states that the BDD configuration parameters are “adopted” (inherited) without naming them  Should there instead be a table with all of the configuration parameters named, with a note identifying the inherited ones, to be consistent with the CSTS SFW?  DECISION – Table will contain both inherited and locally-defined parameters  NOTE: some issues in CSTS SFW with regard to the type casting of configuration parameters

4. www.ccsds.org Outstanding Issues/ Required Cleanup (3 of 3) 4  Need to align treatment of BTDMD NOTIFY invocation ASN.1 with SFW BDD ASN.1 declaration  SFW treatment does not address notifyInvocationExtension  ICS Proforma annex needs to be aligned with SFW  Annex with cross–references to CSTS SFW sections needs to be created  Informative annex needs to be added that provides examples of Atomic Segments  The Information Query procedure is currently constrained to procedure configuration parameter values. WH suggests allowing it to be used to query the monitored parameters of any of the FRs that support tracking data generation  Preliminary analysis (last fall) was that such a change would be possible, but there was a question as to how it would be specified so as to be unambiguous and consistent across implementations? I.e., how would the behavior of the GET operation be phrased?  Needs to be addressed in the light of recent SFW updates