<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Organization and Processes for the Consultative Committee for Space Data Systems</title>
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
Dear Mario,</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
It appears that we have a somewhat confused situation here, compounded, perhaps, of inexperience and an eagerness to get things moving. I do appreciate you digging out the "audit trail" of emails, as painful as that might have been. What it makes clear to
me, and I hope to the others, is that while the first, technical condition, on the CESG poll was satisfied the second condition that I put on the original CESG approval poll was not satisfied and proper procedures for nominating and voting on the WG chair
were not followed.</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
Please see the quoted sections of the CCSDS Organization and Procedures Manual, A02.1-Y-4C1, dated April 2014, shown below.</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
My suggestion is that we accept the CMC poll to create the WG, since they have approved the WG and the resources, and that is their prerogative in any event (see Sec 2.3.3). However, I think that we must create a new CESG poll for the WG chair, since that
is the CESG's business and it was never properly handled to begin with (see Sec 2.3.2.3 and 2.3.3.4). </div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
Best regards, Peter</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<div class="page" title="Page 24">
<div class="layoutArea">
<div class="column">
<p><span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPS'; font-weight: 700">2.3.3 WORKING GROUPS
</span></p>
<p><span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPS'; font-weight: 700">2.3.3.1 General
</span></p>
<p><span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPSMT'">The vast majority of the work of CCSDS is done in many Working Groups (WGs) that are clustered into closely related technical Areas. Each WG has a specific published and approved charter
and schedule that it is required to follow and a set of associated resources that must be committed by a sponsor to do the work.</span></p>
<p><span style="font-family: TimesNewRomanPSMT; font-size: 12pt;">No WG will be initiated by CCSDS unless a credible resource profile has been prepared and at least two agencies have agreed to provide the necessary support (see 5.5.2).</span></p>
<p><span style="font-family: TimesNewRomanPSMT; font-size: 12pt;">The WG charters, including the list of documents/products of the WG, and the schedule for those products are maintained in the on-line Framework. The data is entered by the WG chairs, approved
by the CMC, and configuration-managed by the Secretariat in the Framework.</span></p>
<p><span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPSMT'"> </span></p>
</div>
</div>
</div>
</div>
<div>
<div class="page" title="Page 20">
<div class="layoutArea">
<div class="column">
<p style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPS'; font-weight: 700">2.3.2.3 CESG Responsibilities
</span></p>
<p style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPSMT'">The CESG is specifically responsible for the following:</span></p>
<p></p>
<div class="page" title="Page 20">
<div class="layoutArea">
<div class="column">
<ol style="list-style-type: none">
<li>
<p><span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPSMT'">c) reviewing the proposed composition and program of work of all new WGs in each Area to ensure that they are technically consistent, contribute to a cohesive set of CCSDS architectural
concepts, properly respect the need for smooth evolution of the large installed base of CCSDS-compatible systems, and are not otherwise disruptive to the needs of customers;
</span></p>
</li><li>
<p><span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPSMT'">d) making recommendations to the CMC concerning which new WGs should be approved; </span></p>
</li></ol>
</div>
</div>
</div>
<div class="page" title="Page 21">
<div class="layoutArea">
<div class="column">
<ol start="7" style="list-style-type: none">
<li>
<p><span style="font-size: 12.000000pt; font-family: 'TimesNewRomanPSMT'">n) approving WG Chairs and Deputy Chairs; </span></p>
</li></ol>
</div>
</div>
</div>
<div class="page" title="Page 26">
<div class="layoutArea">
<div class="column">
<p><span style="font-family: TimesNewRomanPS; font-size: 12pt; font-weight: 700;">2.3.3.4 Working Group Chairs</span></p>
</div>
</div>
</div>
<p><span style="font-family: TimesNewRomanPSMT; font-size: 12pt;">Working Group chairs are nominated by an Area Director and approved by the CESG. Candidates for selection as WG chairs must be recognized as a leading technical expert in the field covered by
that WG. Candidates may come from any organization (including industry) and do not have to be employees of space agencies.</span><span style="color: rgb(0, 0, 0); font-family: TimesNewRomanPSMT; font-size: 12pt;"> </span></p>
</div>
</div>
</div>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span><<a href="mailto:cesg-bounces@mailman.ccsds.org">cesg-bounces@mailman.ccsds.org</a>> on behalf of Mario Merri <<a href="mailto:Mario.Merri@esa.int">Mario.Merri@esa.int</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, July 7, 2015 at 9:48 AM<br>
<span style="font-weight:bold">To: </span>Brian Oliver <<a href="mailto:briano@aiaa.org">briano@aiaa.org</a>><br>
<span style="font-weight:bold">Cc: </span>CCSDS Engineering Steering Group - CESG Exec <<a href="mailto:cesg@mailman.ccsds.org">cesg@mailman.ccsds.org</a>>, Nestor Peccia <<a href="mailto:Nestor.Peccia@esa.int">Nestor.Peccia@esa.int</a>>, Nick Tongson <<a href="mailto:nickt@aiaa.org">nickt@aiaa.org</a>>,
CMC <<a href="mailto:cmc@mailman.ccsds.org">cmc@mailman.ccsds.org</a>>, Roger Thompson <<a href="mailto:Roger.Thompson@scisys.co.uk">Roger.Thompson@scisys.co.uk</a>>, "<a href="mailto:Mehran.Sarkarati@esa.int">Mehran.Sarkarati@esa.int</a>" <<a href="mailto:Mehran.Sarkarati@esa.int">Mehran.Sarkarati@esa.int</a>><br>
<span style="font-weight:bold">Subject: </span>[CESG] [Cesg-all] Results of CESG Polls closing 23 April 2015<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div><font size="2" face="Arial">Dear Brian,</font> <br>
<br>
<font size="2" face="Arial">as you know I am a junior AD and might not have followed the process to the letter. Please apologies if I have made any involuntary mistake. However, I (painfully) reconstructed the major events - see below - and I believe that all
the major players have always been involved, made aware of the status of matters, and asked for their agreement if this was necessary. I also thought that the successful closure of the CESG poll were a pre-requisite for CCSDS Secretariat to open the subsequent
CMC poll. This induced me to believe that all the issues with the CESG poll were considered solved.
</font><br>
<br>
<font size="2" face="Arial">I also attach below the notes of 19May15 where Peter confirms his agreement to his CESG conditions and the Concept Paper on which this agreement is based.</font><br>
<br>
<font size="2" face="Arial">Please let me know if this solves all your issues or if I need to take any additional action.</font><br>
<br>
<font size="2" face="Arial">Regards,</font> <br>
<br>
<font size="2" face="Arial">__Mario</font> <br>
<br>
<font size="2" face="Arial">====================================</font> <br>
<br>
<font size="2" face="Arial">23Apr15 CESG poll closes</font> <br>
<br>
<font size="2" face="Arial">24Apr15 Everyone APPROVEs UNCONDITIONALLY except Peter Shames who APPROVEs WITH CONDITIONS and raises the following 2 concerns:</font><br>
<br>
<font size="2" face="Arial">"1) The focus in most of these materials seems to be on SM&C and how it can solve the problem, rather than on Mission Planning and a clear presentation of what they need. This is both "cart before the horse" and looks like an overly
tight binding that may be detrimental to the overall usability of the resulting standards.
<br>
<br>
2) The WG leadership is exclusively Euro-centric. Since there does appear to be a significant North American interest in this it would be sensible to broaden the coverage to recognize that."</font><br>
<br>
<font size="2" face="Arial">24Apr15 Mehran Sarkarati replies to Peter addressing the 2 conditions.</font><br>
<br>
<font size="2" face="Arial">27Apr15 Mario Merri addresses condition 2 by asking CMC for Agencies' nominations for participation to the MP&S WG with due date 08May15. Only CNSA replies on 07May15 by offering support to the WG as member/contributor.</font><br>
<br>
<font size="2" face="Arial">12May15 After some email exchange between Mehran and Peter, the updated version of the MP&S Concept Paper (v4) is sent to Peter</font><br>
<br>
<font size="2" face="Arial">13May15 Peter considers the updated version of the MP&S Concept Paper (v4) "much improved", but he still has two major issues.</font><br>
<br>
<font size="2" face="Arial">18May15 Peter further expands on his concerns</font> <br>
<br>
<font size="2" face="Arial">19May15 Mario and Brigitte address Peter's concerns from the MOIMS point of view and kindly ask him to "confirm that your conditions for the establishment of the Planning and Scheduling WG are satisfied."</font><br>
<br>
<font size="2" face="Arial">19May15 Peter confirms that his conditions are satisfied (see attached note).</font><br>
<br>
<font size="2" face="Arial">20May15 Mario confirms to the CCSDS Secretariat that Peter's conditions have been resolved and asks to issue the CMC poll.</font><br>
<br>
<font size="2" face="Arial">23May15 CCSDS Secretariat opens the CMC poll that asks for the creation of the SM&P WG with Mehran Sarkarati as Chair and R. Thompson as Deputy Chair.
</font><br>
<br>
<font size="2" face="Arial">05Jun15 CMC poll closes. Everyone votes ADOPT, except for CNES and ESA who vote ADOPT PROVISIONALLY and raise the (same) concern: to initially commit only for the production of the GB</font><br>
<br>
<font size="2" face="Arial">14Jun15 Mario addresses the CNES and ESA conditions and obtains their agreements on the proposed way forward.</font><br>
<br>
<font size="2" face="Arial">15Jun15 Mario provides evidence to the CCSDS Secretariat that the conditions raised by CNES and ESA have been satisfied and asks for the creation of the MP&S WG.</font><br>
<br>
<font size="2" face="Arial">21Jun15 The CCSDS Secretariat acknowledges the reception of the request for the creation of the MP&S WG and asks for a few days for the implementation as "I am currently on vacation"</font><br>
<br>
<br>
<font size="1" color="#800080" face="sans-serif">----- Forwarded by Mario Merri/esoc/ESA on 07/07/2015 16:22 -----</font><br>
<br>
<font size="1" color="#5f5f5f" face="sans-serif">From: </font><font size="1" face="sans-serif">"Shames, Peter M (312B)" <<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>></font><br>
<font size="1" color="#5f5f5f" face="sans-serif">To: </font><font size="1" face="sans-serif">"<a href="mailto:Mario.Merri@esa.int">Mario.Merri@esa.int</a>" <<a href="mailto:Mario.Merri@esa.int">Mario.Merri@esa.int</a>>,
</font><br>
<font size="1" color="#5f5f5f" face="sans-serif">Cc: </font><font size="1" face="sans-serif">"<a href="mailto:brigitte.behal@cnes.fr">brigitte.behal@cnes.fr</a>" <<a href="mailto:brigitte.behal@cnes.fr">brigitte.behal@cnes.fr</a>>, "<a href="mailto:danford.s.smith@nasa.gov">danford.s.smith@nasa.gov</a>"
<<a href="mailto:danford.s.smith@nasa.gov">danford.s.smith@nasa.gov</a>>, "<a href="mailto:Mehran.Sarkarati@esa.int">Mehran.Sarkarati@esa.int</a>" <<a href="mailto:Mehran.Sarkarati@esa.int">Mehran.Sarkarati@esa.int</a>>, "<a href="mailto:Nestor.Peccia@esa.int">Nestor.Peccia@esa.int</a>"
<<a href="mailto:Nestor.Peccia@esa.int">Nestor.Peccia@esa.int</a>>, Roger Thompson <<a href="mailto:Roger.Thompson@scisys.co.uk">Roger.Thompson@scisys.co.uk</a>></font><br>
<font size="1" color="#5f5f5f" face="sans-serif">Date: </font><font size="1" face="sans-serif">19/05/2015 23:20</font><br>
<font size="1" color="#5f5f5f" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Re: Establishing the Planning and Scheduling WG</font><br>
<hr noshade="">
<br>
<br>
<br>
<font size="2" face="Calibri">Mario, et al,</font> <br>
<br>
<font size="2" color="blue" face="Arial"><b>London agreement</b></font> <br>
<font size="2" face="Calibri">I confirm the agreement from London. But I note the following:</font>
<ul>
<li><font size="3" color="blue" face="Arial">CCSDS shall maintain a single reference architecture and lexicon</font><font size="3" face="Arial"></font><font size="3" color="#ff8100" face="Arial"><b>(The CCSDS does not yet have this and there are not, as yet,
any resources to complete this work. It is desperately needed.)</b></font></li><li><font size="3" color="blue" face="Arial">Cross Support Transfer Services (CSTS) Framework and Cross Support Service Management (CSSM) shall be used for interfaces between the mission control systems and the ground network/stations, including for ground
station planning and scheduling. </font><font size="3" color="#ff8100" face="Arial"><b>(Agreed)
</b></font></li><li><font size="3" color="blue" face="Arial">MOIMS Mission Operations Framework and Services shall be used for interfaces between the mission control systems and all other mission operations ground assets (except ground stations) and for E2E space-ground MO
services via encapsulation/SLE tunneling, including mission planning and scheduling. </font><font size="3" color="#ff8100" face="Arial"><b>(Agreed)
</b></font></li><li><font size="3" color="blue" face="Arial">The CESG shall enforce a clear apportionment of tasks to WGs consistent with the above frameworks. Deviations are possible, but they need to be justified and approved by CESG.</font><font size="3" face="Arial"> </font><font size="2" color="#ff8100" face="Arial"><b>(Agreed,
but note that the mission planning community may wish to ensure that their systems are not forced to adopt the SM&C framework in order to be able to use the mission planning WG results)
</b></font></li></ul>
<font size="3" color="blue" face="Arial"><b>MAL XML is a data model language</b><br>
Despite what you say and despite we do not have an explicit background in computer science, the MAL XML is a data modelling language.</font><br>
<br>
<font size="2">The COM and MAL define data structures using a tabular form. This is an abstract approach. These tables are not a "data model language". XML can be thought of as a data modeling language, but it is a weak one. The use made of XML in MAL
and COM schemas is similarly abstract. It will only be "realized" when it is used to define actual data structures for a particular application domain and then bound to a data mapping (which could be a different form of XML) and a transport format. It is
this binding to a concrete data structure representation and "technology" that renders the MAL and COM interoperable, but then only within systems that use the exact same binding. The XML schema in the MAL and COM are not the same as a concrete XML (or other)
transport binding.</font> <br>
<br>
<font size="3">As yet there is no SM&C / MO to XML transport binding, but I see that one is now planned to be created in the next few years. This interoperable XML binding does not yet exist, so it will need to be specified in order for a direct XML transport
of planning and scheduling messages, as files, to be possible.</font> <br>
<br>
<font size="3" color="blue" face="Arial"><b>Way forward</b></font> <br>
<font size="3" color="blue" face="Arial">we consider this discussion closed and kindly request that you confirm that your conditions for the establishment of the Planning and Scheduling WG are satisfied.</font><br>
<br>
<font size="3">I remain concerned that the Mission Planning and Scheduling WG is being too tightly constrained by the requirement for them to adopt the whole MAL and COM superstructure in order to define what might be some simple XML data exchange formats.
That said, I acknowledge that you are adamant that this is the only acceptable way forward.
</font><br>
<br>
<font size="3">Since the people I have consulted with are willing to accept these constraints I will set aside my misgivings, but wish to go on record that I think there is an issue here.</font><br>
<br>
<font size="3">Best regards, Peter</font> <br>
<br>
<br>
<br>
<br>
<font size="2" face="Calibri"><b>From: </b>Mario Merri <</font><a href="mailto:Mario.Merri@esa.int"><font size="2" color="blue" face="Calibri"><u>Mario.Merri@esa.int</u></font></a><font size="2" face="Calibri">><b><br>
Date: </b>Tuesday, May 19, 2015 at 10:03 AM<b><br>
To: </b>Peter Shames <</font><a href="mailto:peter.m.shames@jpl.nasa.gov"><font size="2" color="blue" face="Calibri"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size="2" face="Calibri">><b><br>
Cc: </b>Brigitte Behal <</font><a href="mailto:Brigitte.Behal@cnes.fr"><font size="2" color="blue" face="Calibri"><u>Brigitte.Behal@cnes.fr</u></font></a><font size="2" face="Calibri">>, Dan Smith <</font><a href="mailto:danford.s.smith@nasa.gov"><font size="2" color="blue" face="Calibri"><u>danford.s.smith@nasa.gov</u></font></a><font size="2" face="Calibri">>,
"</font><a href="mailto:Mehran.Sarkarati@esa.int"><font size="2" color="blue" face="Calibri"><u>Mehran.Sarkarati@esa.int</u></font></a><font size="2" face="Calibri">" <</font><a href="mailto:Mehran.Sarkarati@esa.int"><font size="2" color="blue" face="Calibri"><u>Mehran.Sarkarati@esa.int</u></font></a><font size="2" face="Calibri">>,
Nestor Peccia <</font><a href="mailto:Nestor.Peccia@esa.int"><font size="2" color="blue" face="Calibri"><u>Nestor.Peccia@esa.int</u></font></a><font size="2" face="Calibri">>, Roger Thompson <</font><a href="mailto:Roger.Thompson@scisys.co.uk"><font size="2" color="blue" face="Calibri"><u>Roger.Thompson@scisys.co.uk</u></font></a><font size="2" face="Calibri">><b><br>
Subject: </b>Establishing the Planning and Scheduling WG</font> <br>
<br>
<font size="3" face="Arial">Dear Peter,<br>
<br>
At this point Brigitte and I would like to intervene in the discussion to express our joint opinion.<b><br>
<br>
MAL XML is a data model language</b><br>
Despite what you say and despite we do not have an explicit background in computer science, the MAL XML is a data modelling language. In fact, it unambiguously models in an abstract manner all semantical data objects that are exchanged during the dialogue between
service provider and consumer. Have a a look at <u>any service</u> in the COM or in the to-be-published M&C service book where all the details of the dialogue is unambiguously defined. As a consequence of this modelling approach, these objects can be represented
(encoded) in different technologies provided a mapping exists. A mapping to XML is being produced and it is a newly approved project in CCSDS.<b><br>
<br>
CCSDS is a jungle of data modelling languages</b><br>
As you correctly pointed out, the CCSDS uses several data modelling languages and each working group does basically what he wants. We do not believe this is a good approach for a standardisation organisation. Even in the CSS area, ASN.1 is used predominantly
in the CSTS sub-area, while SM has used (BB) and is still using (Simple schedule) UML mapped to XML (BB). In the MOIMS area, we would like to change this and enforce a common approach at least for all the new MO services that are planned. We kindly recall
you that the Planning and Scheduling services are among them (see SM&C charter), which - together with the other MO Services - will provide a homogeneous and inter-working set of services where the proprieties of MAL and COM will be exploited at their best.
Clearly at this time we have no ambition of retrofitting this approach into historical MOIMS WGs, such as DAI and NAV, as we respect their heritages, but for the new services this is our intention.<b><br>
<br>
London agreement</b><br>
During the London CCSDS meeting, we cut an agreement at CCSDS level that any service involving a ground station as ending point was handled by CSS while any other service would be MO service. More than that I quote below part of the agreed resolution that was
presented by CESG to CMC (see CESG-Report-to-CMC-Fall14-Items attentionCMC.pptx):</font>
<ul>
<li><font size="3" color="blue" face="Arial">CCSDS shall maintain a single reference architecture and lexicon</font></li><li><font size="3" color="blue" face="Arial">Cross Support Transfer Services (CSTS) Framework and Cross Support Service Management (CSSM) shall be used for interfaces between the mission control systems and the ground network/stations, including for ground
station planning and scheduling.</font><font size="3" face="Times New Roman"> </font>
</li><li><font size="3" color="blue" face="Arial">MOIMS Mission Operations Framework and Services shall be used for interfaces between the mission control systems and all other mission operations ground assets (except ground stations) and for E2E space-ground MO
services via encapsulation/SLE tunneling, including mission planning and scheduling.
</font></li><li><font size="3" color="blue" face="Arial">The CESG shall enforce a clear apportionment of tasks to WGs consistent with the above frameworks. Deviations are possible, but they need to be justified and approved by CESG</font></li></ul>
<font size="3" face="Arial"><br>
The Planning and Scheduling services clearly falls in the third bullet and we would like the agreement to be honoured. On the other hand, we have accepted you comment that an organisation may be interested in a mere file exchange of planning information, which
is now covered in the plan of work. Please note that the third bullet explicitly confirm the agreement that the MO Framework (MAL + COM) shall be used for defining MOIMS MO Services.
<b><br>
<br>
Way forward</b><br>
With the above, in particular the London agreement, we consider this discussion closed and kindly request that you confirm that your conditions for the establishment of the Planning and Scheduling WG are satisfied.<br>
<br>
Best regards,<br>
<br>
Brigitte & Mario</font><font size="2" face="Calibri"> <br>
<br>
<br>
</font><font size="1" color="#5f5f5f" face="sans-serif"><br>
From: </font><font size="1" face="sans-serif">"Shames, Peter M (312B)" <</font><a href="mailto:peter.m.shames@jpl.nasa.gov"><font size="1" color="blue" face="sans-serif"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size="1" face="sans-serif">></font><font size="1" color="#5f5f5f" face="sans-serif"><br>
To: </font><font size="1" face="sans-serif">"</font><a href="mailto:Mehran.Sarkarati@esa.int"><font size="1" color="blue" face="sans-serif"><u>Mehran.Sarkarati@esa.int</u></font></a><font size="1" face="sans-serif">" <</font><a href="mailto:Mehran.Sarkarati@esa.int"><font size="1" color="blue" face="sans-serif"><u>Mehran.Sarkarati@esa.int</u></font></a><font size="1" face="sans-serif">>,
</font><font size="1" color="#5f5f5f" face="sans-serif"><br>
Cc: </font><font size="1" face="sans-serif">"</font><a href="mailto:brigitte.behal@cnes.fr"><font size="1" color="blue" face="sans-serif"><u>brigitte.behal@cnes.fr</u></font></a><font size="1" face="sans-serif">" <</font><a href="mailto:brigitte.behal@cnes.fr"><font size="1" color="blue" face="sans-serif"><u>brigitte.behal@cnes.fr</u></font></a><font size="1" face="sans-serif">>,
"</font><a href="mailto:danford.s.smith@nasa.gov"><font size="1" color="blue" face="sans-serif"><u>danford.s.smith@nasa.gov</u></font></a><font size="1" face="sans-serif">" <</font><a href="mailto:danford.s.smith@nasa.gov"><font size="1" color="blue" face="sans-serif"><u>danford.s.smith@nasa.gov</u></font></a><font size="1" face="sans-serif">>,
"</font><a href="mailto:Mario.Merri@esa.int"><font size="1" color="blue" face="sans-serif"><u>Mario.Merri@esa.int</u></font></a><font size="1" face="sans-serif">" <</font><a href="mailto:Mario.Merri@esa.int"><font size="1" color="blue" face="sans-serif"><u>Mario.Merri@esa.int</u></font></a><font size="1" face="sans-serif">>,
"</font><a href="mailto:Nestor.Peccia@esa.int"><font size="1" color="blue" face="sans-serif"><u>Nestor.Peccia@esa.int</u></font></a><font size="1" face="sans-serif">" <</font><a href="mailto:Nestor.Peccia@esa.int"><font size="1" color="blue" face="sans-serif"><u>Nestor.Peccia@esa.int</u></font></a><font size="1" face="sans-serif">>,
"Roger Thompson" <</font><a href="mailto:Roger.Thompson@scisys.co.uk"><font size="1" color="blue" face="sans-serif"><u>Roger.Thompson@scisys.co.uk</u></font></a><font size="1" face="sans-serif">></font><font size="2" face="Calibri"></font><font size="1" color="#5f5f5f" face="sans-serif"><br>
Date: </font><font size="1" face="sans-serif">18/05/2015 21:13</font><font size="1" color="#5f5f5f" face="sans-serif"><br>
Subject: </font><font size="1" face="sans-serif">Re: Updated MO Concept Paper</font><font size="2" face="Calibri"><br>
</font>
<hr noshade="">
<font size="2" face="Calibri"><br>
<br>
</font><font size="2" face="Calibri"><br>
Dear Mehran,</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
It has taken a while to chew on this, in part because I was dealing with similar issues of definitions and terminology elsewhere in CCSDS, in the CSS and SOIS areas. I suspect that you are not going to like this answer, but it is based upon an analysis of most
of the CCSDS standards (and of other work outside of CCSDS).</font><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><br>
What I find, in looking across all of the sets of CCSDS standards related to "data or information models", is that we, CCSDS, have no standards for ourselves. This is not a new observation, and it is a problem that we have been growing, "organically" if you
will, for some time. Part of it has to do with our somewhat decentralized organizational structure, where areas have a lot of autonomy, part of it has to do with the inexorable advance of technology. We, and the technology we use, are no longer where we
were 30 years ago, nor even five years ago.</font><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><br>
In CCSDS today we have many "data modeling languages" several of them developed in MOIMS, but also from other area. I can quickly identify the following from our publications:</font><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><br>
- DEDSL (several flavors)</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
- EAST</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
- ASN.1</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
- OWL ontologies</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
- MAL & COM abstractions</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
- XML (DTD, Schema, and other)</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
- ASCII encoded English</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
- various ASCII files and tables defined in documents, including those for the SCID, MACAO, SFDU, PVL, Agency, Observer, and PoC registries<br>
- and the CCSDS Glossary (which so far just slams all of these loosely defined terms together in one place)</font><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><br>
CSS has uniformly chosen to adopt ASN.1, which at least has the benefit of being a widely used international standard with a formal language and some already well defined and documented translations into XML, JSON, and compact binary forms. They also are making
effective use of ISO OIDs, which are unambiguous, and registered, object identifiers that are grounded in another ISO spec. The ASN.1 specs, because they use a structured language, tend to be formal, compact, and directly interpretable. ASN.1 can be compiled
and transformed into code or other data representations.</font><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><br>
The SOIS is now adopting the approach of defining a formal dictionary of terms using an ontology, with a representation in OWL. OWL, of course, has an XML binding, but it is the formal structure of OWL that is really of interest. OWL has constructs to define
objects, their properties, their relationships, operations, classes, and instances. It has built in formalisms and tools that can be used to assess it and transform it. Using OWL requires you to formally define what you mean in an interpretable way.</font><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><br>
In contrast, I do not believe that there any uniformity of data, or terminology, or prepresentations in MOIMS. MOIMS has not uniformly adopted XML, it has spawned at least 5 or 6 of the data modeling languages listed above. Nor is there yet anything like
a commonly adopted representation. Even if I were to accept your assertion "</font><font size="2" color="blue" face="Calibri">selection of the XML schema is to ensure consistency within MOIMS that all data models are specified in a harmonised way</font><font size="2" face="Calibri">",
which appears, given the evidence just stated, to not quite be accurate, XML schema are not a data model, they are a data representation. There is no consistent data or information model in use across MOIMS, nor even in just SM&C. And there is not yet
published, even just within SM&C, a formal mapping of the SM&C abstractions to XML.</font><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><br>
The closest thing I could find to information model definitions SM&C are the COM (521x1b) and the MORM, 520x1m These tend to be rather "anecdotal" in form, descriptive rather than crisp definitions. Here is an example from the COM:</font><font size="2" face="Calibri"></font><font size="3" color="blue" face="Calibri"><br>
Object: </font><font size="3" color="blue" face="TimesNewRomanPSMT">A thing which is recognised as being capable of an independent existence and which can be uniquely identified. An object may be a physical object such as a spacecraft or a ground station, an
event such as an eclipse, or a concept such as telemetry parameter. It forms the fundamental part of a service specification, e.g., a parameter definition, a parameter value at a given point in time, a command. There are no requirements on what an object may
be except that it must be possible to uniquely identify an instance of it. </font>
<p><font size="2" face="Calibri">This "definition" includes at least four or five separate concepts, including several implied relationships such as "an object may be a fundamental part of a service spec". The other definitions I found in the MORM and the
COM are similar in form to this. Given your CS background I hope that you would agree that none of this is anything like a formal "information model".</font><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><br>
There are, of course, many different ways to represent and define information models, i.e. objects and their relationships. CSS has chosen one (ASN.1), SOIS has chosen another (ontology & OWL). The TDE work we started used another one called Fact Based Modeling
(FBM). All have similar properties of formalism and transformability. Right now I do not believe that MOIMS, as a whole, has chosen one, or even two. There are several, and the particular one you identified, I.e. XML, is not an information modeling approach,
it is a data representation approach. </font><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><br>
I agree that it would be really good if MOIMS did have some sort of overall information model, but I cannot agree that it has one now.</font><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><br>
The second issue, that of forcing adoption of the MAL service structures onto this new planning working group still seems to me to be off the mark. My suggestion is that you only include this as one possible approach for the future work of defining a service
definition, and that you leave the work of defining the necessary mission planning informaiton model and file or message structures for exchange to this new working group without these restrictions. I do think that they need some guidance as to how best
to approach that information modeling problem, but I do not think that saying "use XML" or "use the MAL" are adequate, or even necessary, for this purpose.
</font><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><br>
Best regards, Peter</font><font size="2" face="Calibri"> <br>
<br>
<br>
</font><font size="2" face="Calibri"><br>
On 5/13/15, 11:05 PM, "</font><a href="mailto:Mehran.Sarkarati@esa.int"><font size="2" color="blue" face="Calibri"><u>Mehran.Sarkarati@esa.int</u></font></a><font size="2" face="Calibri">" <</font><a href="mailto:Mehran.Sarkarati@esa.int"><font size="2" color="blue" face="Calibri"><u>Mehran.Sarkarati@esa.int</u></font></a><font size="2" face="Calibri">>
wrote:</font><font size="2" face="Calibri"> <br>
<br>
</font><font size="2" face="Calibri"><br>
Dear Peter,</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
Thanks for your quick feedback.</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
The second point you have raised seems to be easier to clarify. If I<br>
understand correctly you are concerned about "exchange" of the information<br>
related to the mission planning as XML. For this, I agree with you that XML<br>
is one of the choices, compact binary, JASON or whatever that fits the needs<br>
of an organisation must be supported. We propose the use of XML schema as an<br>
abstract but formal data modelling language at design time. At run time, for<br>
a particular setup/deployment the actual messages can be exchanged in JASON<br>
or any other "encoding" that fits the purpose.<br>
The selection of the XML schema is to ensure consistency within MOIMS that<br>
all data models are specified in a harmonised way.</font><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><br>
The first point is where I see we are going a bit in cycles. We had two calls<br>
for interest and two BOFs for mission planning. The report from the two calls<br>
for interest, which was also published as a paper in the SpaceOps high-lights<br>
clearly the user need for defining mission planning services. At the BOF in<br>
London strong concerns were raised to ensure that whatever we do, at the end<br>
it shall be possible to exchange the mission planning information without<br>
being forced to use a service framework and by means of simple file exchange.<br>
We believe these two objectives were both valid and both supported by the<br>
community. It was therefore agreed to first concentrate on defining an<br>
information model and in a second step (not third or forth) to define the<br>
services.</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
We have respected these two objectives and the order of the priority in the<br>
charter and the white paper. Btw, the scope section of the white book is a<br>
copy and paste from the charter, which you said is ok in the previous note.<br>
When defining the information model it is important to be "service aware"<br>
this has little impact on the final results for those who do not care about<br>
services but want to simply exchange the information, where as not doing it<br>
has a considerable impact for the second step. In effect the final result of<br>
the work will be a formal data or information model specified as XML schema,<br>
which does not impose the use of MO Framework. Organisations who do not want<br>
to use service, will have a concrete data model for planning requests, plans,<br>
schadule and other involved entities. They can write concrete XML documents<br>
or JASON or binary messages compliant to this model and exchange it via<br>
files.</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
However within MOIMS, we want to ensure that there is a consistent<br>
information model that establishes relations between the entities defined for<br>
different domains (e.g. Actions, Alerts, Events, Checks, Parameters,<br>
Aggregations and Planning Request, Plan, Schedule, PlanningRequestStatus,<br>
etc.).</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
I believe the use of CSTS for Ground Stations and use of MO Framework for<br>
things outside the Ground stations reflects the "cut" between ESA , NASA and<br>
other agencies which was agreed during the CCSDS Meetings in London.</font><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><br>
Now, I am afraid that in all this discussion, the practical impact may seem<br>
larger than it actually is so that we are having a discussion at conceptual<br>
level rather than on practical level. That is why I would like to highlight<br>
again that defining the information model as suggested by the concept paper<br>
and the charter would not have practical disadvantages for people who do not<br>
care about services.</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
In view of above, I suggest that I update the paper to clarify point (2) and<br>
accepting your text modifications. For point 1, I would add text that<br>
explains that in practical terms defining the information model while being<br>
"service aware" would mean separation of data from meta-data in different<br>
sections of the document and using certain namespaces and ensuring<br>
consistency with the already defined information model of other MOIMS areas.</font><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><br>
Would this be an acceptable approach?</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
Regards</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
Mehran</font><font size="2" face="Calibri"> <br>
<br>
</font><font size="2" face="Calibri"><br>
On 13 May 2015, at 00:49, Shames, Peter M (312B)<br>
<</font><a href="mailto:peter.m.shames@jpl.nasa.gov"><font size="2" color="blue" face="Calibri"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size="2" face="Calibri">> wrote:</font><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><br>
Hi Mehran,</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
This is much improved, but I do still have two major issues.</font><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><br>
What I got from the community was that they would value having a clear set<br>
of standards that they can use with their existing planning systems. This<br>
charter says "yes, we'll give you an info model for files, but we are really<br>
going to require the use of the MO Framework, even to define these forms."<br>
While I recognize the desireability of this kind of approach for any<br>
community that has chosen to adopt the MO Framework, I doubt that anyone who<br>
has not made that choice will find this to be attractive. I think you really<br>
need to carefully consider what these specs must do for the users, and as a<br>
second or third level consideration map them into the MO, not the other way<br>
around.</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
Along those same lines, this white paper seems to make the foregone<br>
conclusion that XML is the only way to exchange these data (and that XML is<br>
be derived from the MO model, see issue 1). XML is certainly a strong<br>
possibility, but there are also other very effective approaches for portably<br>
defining data structures, such as ASN.1, BNF, or even JSON, etc that are<br>
equally viable. ASN.1, for instance, has direct translations into XML, JSON,<br>
and even compact binary forms. I think you should leave that door more open<br>
for the planning community to decide what they think is most viable in the<br>
long run.</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
There are a few other minor items marked in the text, but there are the two<br>
big ones I identified.</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
Regards, Peter</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
From: "</font><a href="mailto:Mehran.Sarkarati@esa.int"><font size="2" color="blue" face="Calibri"><u>Mehran.Sarkarati@esa.int</u></font></a><font size="2" face="Calibri">" <</font><a href="mailto:Mehran.Sarkarati@esa.int"><font size="2" color="blue" face="Calibri"><u>Mehran.Sarkarati@esa.int</u></font></a><font size="2" face="Calibri">><br>
Date: Tuesday, May 12, 2015 at 12:20 PM</font><font size="2" face="Calibri"> </font>
<font size="2" face="Calibri"><br>
To: Peter Shames <</font><a href="mailto:peter.m.shames@jpl.nasa.gov"><font size="2" color="blue" face="Calibri"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size="2" face="Calibri">><br>
Cc: Brigitte Behal <</font><a href="mailto:Brigitte.Behal@cnes.fr"><font size="2" color="blue" face="Calibri"><u>Brigitte.Behal@cnes.fr</u></font></a><font size="2" face="Calibri">>, Dan Smith<br>
<</font><a href="mailto:danford.s.smith@nasa.gov"><font size="2" color="blue" face="Calibri"><u>danford.s.smith@nasa.gov</u></font></a><font size="2" face="Calibri">>, Mario Merri <</font><a href="mailto:Mario.Merri@esa.int"><font size="2" color="blue" face="Calibri"><u>Mario.Merri@esa.int</u></font></a><font size="2" face="Calibri">>,
Nestor Peccia</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
<</font><a href="mailto:Nestor.Peccia@esa.int"><font size="2" color="blue" face="Calibri"><u>Nestor.Peccia@esa.int</u></font></a><font size="2" face="Calibri">>, Roger Thompson <</font><a href="mailto:Roger.Thompson@scisys.co.uk"><font size="2" color="blue" face="Calibri"><u>Roger.Thompson@scisys.co.uk</u></font></a><font size="2" face="Calibri">><br>
Subject: Re: Updated MO Concept Paper</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
Peter,</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
I did send a normal .docx document. No idea what went wrong.<br>
Second try.</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
I am attaching both .doc and .pdf versions.</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
Regards</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
Mehran</font><font size="2" face="Calibri"> <br>
<br>
<br>
<br>
</font><font size="2" face="Calibri"><br>
Dr. Mehran Sarkarati</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
Head Application And Special Projects Section</font><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><br>
ESA – European Space Agency</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
ESOC / HSO-GDA</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
Robert-Bosch-Str. 5</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
64293 Darmstadt</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
Germany</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
Tel: +49 6151 903225</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
Email: </font><a href="mailto:mehran.sarkarati@esa.int"><font size="2" color="blue" face="Calibri"><u>mehran.sarkarati@esa.int</u></font></a><font size="2" face="Calibri"><br>
<br>
<br>
</font><font size="2" face="Calibri"><br>
From: "Shames, Peter M (312B)" <</font><a href="mailto:peter.m.shames@jpl.nasa.gov"><font size="2" color="blue" face="Calibri"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size="2" face="Calibri">><br>
To: "</font><a href="mailto:Mehran.Sarkarati@esa.int"><font size="2" color="blue" face="Calibri"><u>Mehran.Sarkarati@esa.int</u></font></a><font size="2" face="Calibri">" <</font><a href="mailto:Mehran.Sarkarati@esa.int"><font size="2" color="blue" face="Calibri"><u>Mehran.Sarkarati@esa.int</u></font></a><font size="2" face="Calibri">>,<br>
"</font><a href="mailto:Nestor.Peccia@esa.int"><font size="2" color="blue" face="Calibri"><u>Nestor.Peccia@esa.int</u></font></a><font size="2" face="Calibri">" <</font><a href="mailto:Nestor.Peccia@esa.int"><font size="2" color="blue" face="Calibri"><u>Nestor.Peccia@esa.int</u></font></a><font size="2" face="Calibri">>,
"</font><a href="mailto:Mario.Merri@esa.int"><font size="2" color="blue" face="Calibri"><u>Mario.Merri@esa.int</u></font></a><font size="2" face="Calibri">"<br>
<</font><a href="mailto:Mario.Merri@esa.int"><font size="2" color="blue" face="Calibri"><u>Mario.Merri@esa.int</u></font></a><font size="2" face="Calibri">>, "</font><a href="mailto:brigitte.behal@cnes.fr"><font size="2" color="blue" face="Calibri"><u>brigitte.behal@cnes.fr</u></font></a><font size="2" face="Calibri">"
<</font><a href="mailto:brigitte.behal@cnes.fr"><font size="2" color="blue" face="Calibri"><u>brigitte.behal@cnes.fr</u></font></a><font size="2" face="Calibri">>,<br>
Cc: Roger Thompson <</font><a href="mailto:Roger.Thompson@scisys.co.uk"><font size="2" color="blue" face="Calibri"><u>Roger.Thompson@scisys.co.uk</u></font></a><font size="2" face="Calibri">>,<br>
"</font><a href="mailto:danford.s.smith@nasa.gov"><font size="2" color="blue" face="Calibri"><u>danford.s.smith@nasa.gov</u></font></a><font size="2" face="Calibri">" <</font><a href="mailto:danford.s.smith@nasa.gov"><font size="2" color="blue" face="Calibri"><u>danford.s.smith@nasa.gov</u></font></a><font size="2" face="Calibri">><br>
Date: 12/05/2015 17:09</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
Subject: Re: Updated MO Concept Paper</font><font size="2" face="Calibri"><br>
<br>
<br>
<br>
</font><font size="2" face="Calibri"><br>
Mehran,</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
The file that arrived on my end had a suffix of ".doc.hqx". My system has<br>
no idea what to do with this sort of file. Please resend in a normal .doc<br>
or .pdf form.</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
Thanks, Peter</font><font size="2" face="Calibri"> <br>
<br>
<br>
</font><font size="2" face="Calibri"><br>
From: "</font><a href="mailto:Mehran.Sarkarati@esa.int"><font size="2" color="blue" face="Calibri"><u>Mehran.Sarkarati@esa.int</u></font></a><font size="2" face="Calibri">" <</font><a href="mailto:Mehran.Sarkarati@esa.int"><font size="2" color="blue" face="Calibri"><u>Mehran.Sarkarati@esa.int</u></font></a><font size="2" face="Calibri">><br>
Date: Tuesday, May 12, 2015 at 6:54 AM</font><font size="2" face="Calibri"> </font>
<font size="2" face="Calibri"><br>
To: Peter Shames <</font><a href="mailto:peter.m.shames@jpl.nasa.gov"><font size="2" color="blue" face="Calibri"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size="2" face="Calibri">>, Nestor Peccia<br>
<</font><a href="mailto:Nestor.Peccia@esa.int"><font size="2" color="blue" face="Calibri"><u>Nestor.Peccia@esa.int</u></font></a><font size="2" face="Calibri">>, Mario Merri <</font><a href="mailto:Mario.Merri@esa.int"><font size="2" color="blue" face="Calibri"><u>Mario.Merri@esa.int</u></font></a><font size="2" face="Calibri">>,
Brigitte Behal</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
<</font><a href="mailto:Brigitte.Behal@cnes.fr"><font size="2" color="blue" face="Calibri"><u>Brigitte.Behal@cnes.fr</u></font></a><font size="2" face="Calibri">><br>
Cc: Roger Thompson <</font><a href="mailto:Roger.Thompson@scisys.co.uk"><font size="2" color="blue" face="Calibri"><u>Roger.Thompson@scisys.co.uk</u></font></a><font size="2" face="Calibri">>, Dan Smith<br>
<</font><a href="mailto:danford.s.smith@nasa.gov"><font size="2" color="blue" face="Calibri"><u>danford.s.smith@nasa.gov</u></font></a><font size="2" face="Calibri">><br>
Subject: Updated MO Concept Paper</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
Dear Peter,</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
Roger and I have made an effort to update the concept paper, taking your<br>
comments into account.</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
We have approached it with an open mind and have removed the unnecessary<br>
references and background material related to MO.</font><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><br>
Please have a look and see if this updated version is in line with your<br>
expectations and fulfils your raised condition.</font><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><br>
In view of the upcoming CMC meeting on 18 May, I would appreciate a quick<br>
feedback.</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
Kind Regards</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
Mehran</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
This message and any attachments are intended for the use of the addressee<br>
or addressees only.</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
The unauthorised disclosure, use, dissemination or copying (either in whole<br>
or in part) of its</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
content is not permitted.</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
If you received this message in error, please notify the sender and delete<br>
it from your system.</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
Emails can be altered and their integrity cannot be guaranteed by the<br>
sender.</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
Please consider the environment before printing this email.</font><font size="2" face="Calibri"><br>
<br>
</font><font size="2" face="Calibri"><br>
This message and any attachments are intended for the use of the addressee<br>
or addressees only.</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
The unauthorised disclosure, use, dissemination or copying (either in whole<br>
or in part) of its</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
content is not permitted.</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
If you received this message in error, please notify the sender and delete<br>
it from your system.</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
Emails can be altered and their integrity cannot be guaranteed by the<br>
sender.</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="Calibri"><br>
Please consider the environment before printing this email. - CCSDS<br>
Mission Planning Services Concept Paper v4_Clean copy-SEA.pdf<br>
<CCSDS Mission Planning Services Concept Paper v4_Clean copy-SEA.pdf><br>
This message and any attachments are intended for the use of the addressee or addressees only.<br>
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its<br>
content is not permitted.</font><font size="2" face="Calibri"> </font><font size="2" face="Calibri"><br>
If you received this message in error, please notify the sender and delete it from your system.<br>
Emails can be altered and their integrity cannot be guaranteed by the sender.</font><font size="2" face="Calibri"><br>
</font><font size="2" face="Calibri"><br>
Please consider the environment before printing this email.</font><font size="2" face="Calibri"><br>
<br>
</font></p>
<p><font size="2" face="Calibri">This message and any attachments are intended for the use of the addressee or addressees only.<br>
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its<br>
content is not permitted.<br>
If you received this message in error, please notify the sender and delete it from your system.<br>
Emails can be altered and their integrity cannot be guaranteed by the sender.<br>
<br>
Please consider the environment before printing this email.<br>
</font><br>
<br>
</p>
<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>
</div>
</div>
</blockquote>
</span>
</body>
</html>