[CMC] Re: [CESG] [Cesg-all] Results of CESG Polls closing 23 April 2015
Shames, Peter M (312B)
peter.m.shames at jpl.nasa.gov
Tue Jul 7 19:56:15 UTC 2015
Dear Mario,
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.
Please see the quoted sections of the CCSDS Organization and Procedures Manual, A02.1-Y-4C1, dated April 2014, shown below.
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).
Best regards, Peter
2.3.3 WORKING GROUPS
2.3.3.1 General
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.
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).
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.
2.3.2.3 CESG Responsibilities
The CESG is specifically responsible for the following:
1. 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;
2. d) making recommendations to the CMC concerning which new WGs should be approved;
1. n) approving WG Chairs and Deputy Chairs;
2.3.3.4 Working Group Chairs
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.
From: <cesg-bounces at mailman.ccsds.org<mailto:cesg-bounces at mailman.ccsds.org>> on behalf of Mario Merri <Mario.Merri at esa.int<mailto:Mario.Merri at esa.int>>
Date: Tuesday, July 7, 2015 at 9:48 AM
To: Brian Oliver <briano at aiaa.org<mailto:briano at aiaa.org>>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>, Nestor Peccia <Nestor.Peccia at esa.int<mailto:Nestor.Peccia at esa.int>>, Nick Tongson <nickt at aiaa.org<mailto:nickt at aiaa.org>>, CMC <cmc at mailman.ccsds.org<mailto:cmc at mailman.ccsds.org>>, Roger Thompson <Roger.Thompson at scisys.co.uk<mailto:Roger.Thompson at scisys.co.uk>>, "Mehran.Sarkarati at esa.int<mailto:Mehran.Sarkarati at esa.int>" <Mehran.Sarkarati at esa.int<mailto:Mehran.Sarkarati at esa.int>>
Subject: [CESG] [Cesg-all] Results of CESG Polls closing 23 April 2015
Dear Brian,
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.
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.
Please let me know if this solves all your issues or if I need to take any additional action.
Regards,
__Mario
====================================
23Apr15 CESG poll closes
24Apr15 Everyone APPROVEs UNCONDITIONALLY except Peter Shames who APPROVEs WITH CONDITIONS and raises the following 2 concerns:
"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.
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."
24Apr15 Mehran Sarkarati replies to Peter addressing the 2 conditions.
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.
12May15 After some email exchange between Mehran and Peter, the updated version of the MP&S Concept Paper (v4) is sent to Peter
13May15 Peter considers the updated version of the MP&S Concept Paper (v4) "much improved", but he still has two major issues.
18May15 Peter further expands on his concerns
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."
19May15 Peter confirms that his conditions are satisfied (see attached note).
20May15 Mario confirms to the CCSDS Secretariat that Peter's conditions have been resolved and asks to issue the CMC poll.
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.
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
14Jun15 Mario addresses the CNES and ESA conditions and obtains their agreements on the proposed way forward.
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.
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"
----- Forwarded by Mario Merri/esoc/ESA on 07/07/2015 16:22 -----
From: "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
To: "Mario.Merri at esa.int<mailto:Mario.Merri at esa.int>" <Mario.Merri at esa.int<mailto:Mario.Merri at esa.int>>,
Cc: "brigitte.behal at cnes.fr<mailto:brigitte.behal at cnes.fr>" <brigitte.behal at cnes.fr<mailto:brigitte.behal at cnes.fr>>, "danford.s.smith at nasa.gov<mailto:danford.s.smith at nasa.gov>" <danford.s.smith at nasa.gov<mailto:danford.s.smith at nasa.gov>>, "Mehran.Sarkarati at esa.int<mailto:Mehran.Sarkarati at esa.int>" <Mehran.Sarkarati at esa.int<mailto:Mehran.Sarkarati at esa.int>>, "Nestor.Peccia at esa.int<mailto:Nestor.Peccia at esa.int>" <Nestor.Peccia at esa.int<mailto:Nestor.Peccia at esa.int>>, Roger Thompson <Roger.Thompson at scisys.co.uk<mailto:Roger.Thompson at scisys.co.uk>>
Date: 19/05/2015 23:20
Subject: Re: Establishing the Planning and Scheduling WG
________________________________
Mario, et al,
London agreement
I confirm the agreement from London. But I note the following:
* CCSDS shall maintain a single reference architecture and lexicon(The CCSDS does not yet have this and there are not, as yet, any resources to complete this work. It is desperately needed.)
* 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. (Agreed)
* 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. (Agreed)
* 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. (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)
MAL XML is a data model language
Despite what you say and despite we do not have an explicit background in computer science, the MAL XML is a data modelling language.
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.
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.
Way forward
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.
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.
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.
Best regards, Peter
From: Mario Merri <Mario.Merri at esa.int<mailto:Mario.Merri at esa.int>>
Date: Tuesday, May 19, 2015 at 10:03 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Cc: Brigitte Behal <Brigitte.Behal at cnes.fr<mailto:Brigitte.Behal at cnes.fr>>, Dan Smith <danford.s.smith at nasa.gov<mailto:danford.s.smith at nasa.gov>>, "Mehran.Sarkarati at esa.int<mailto:Mehran.Sarkarati at esa.int>" <Mehran.Sarkarati at esa.int<mailto:Mehran.Sarkarati at esa.int>>, Nestor Peccia <Nestor.Peccia at esa.int<mailto:Nestor.Peccia at esa.int>>, Roger Thompson <Roger.Thompson at scisys.co.uk<mailto:Roger.Thompson at scisys.co.uk>>
Subject: Establishing the Planning and Scheduling WG
Dear Peter,
At this point Brigitte and I would like to intervene in the discussion to express our joint opinion.
MAL XML is a data model language
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 any service 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.
CCSDS is a jungle of data modelling languages
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.
London agreement
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):
* CCSDS shall maintain a single reference architecture and lexicon
* 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.
* 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.
* 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
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.
Way forward
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.
Best regards,
Brigitte & Mario
From: "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
To: "Mehran.Sarkarati at esa.int<mailto:Mehran.Sarkarati at esa.int>" <Mehran.Sarkarati at esa.int<mailto:Mehran.Sarkarati at esa.int>>,
Cc: "brigitte.behal at cnes.fr<mailto:brigitte.behal at cnes.fr>" <brigitte.behal at cnes.fr<mailto:brigitte.behal at cnes.fr>>, "danford.s.smith at nasa.gov<mailto:danford.s.smith at nasa.gov>" <danford.s.smith at nasa.gov<mailto:danford.s.smith at nasa.gov>>, "Mario.Merri at esa.int<mailto:Mario.Merri at esa.int>" <Mario.Merri at esa.int<mailto:Mario.Merri at esa.int>>, "Nestor.Peccia at esa.int<mailto:Nestor.Peccia at esa.int>" <Nestor.Peccia at esa.int<mailto:Nestor.Peccia at esa.int>>, "Roger Thompson" <Roger.Thompson at scisys.co.uk<mailto:Roger.Thompson at scisys.co.uk>>
Date: 18/05/2015 21:13
Subject: Re: Updated MO Concept Paper
________________________________
Dear Mehran,
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).
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.
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:
- DEDSL (several flavors)
- EAST
- ASN.1
- OWL ontologies
- MAL & COM abstractions
- XML (DTD, Schema, and other)
- ASCII encoded English
- various ASCII files and tables defined in documents, including those for the SCID, MACAO, SFDU, PVL, Agency, Observer, and PoC registries
- and the CCSDS Glossary (which so far just slams all of these loosely defined terms together in one place)
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.
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.
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 "selection of the XML schema is to ensure consistency within MOIMS that all data models are specified in a harmonised way", 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.
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:
Object: 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.
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".
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.
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.
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.
Best regards, Peter
On 5/13/15, 11:05 PM, "Mehran.Sarkarati at esa.int<mailto:Mehran.Sarkarati at esa.int>" <Mehran.Sarkarati at esa.int<mailto:Mehran.Sarkarati at esa.int>> wrote:
Dear Peter,
Thanks for your quick feedback.
The second point you have raised seems to be easier to clarify. If I
understand correctly you are concerned about "exchange" of the information
related to the mission planning as XML. For this, I agree with you that XML
is one of the choices, compact binary, JASON or whatever that fits the needs
of an organisation must be supported. We propose the use of XML schema as an
abstract but formal data modelling language at design time. At run time, for
a particular setup/deployment the actual messages can be exchanged in JASON
or any other "encoding" that fits the purpose.
The selection of the XML schema is to ensure consistency within MOIMS that
all data models are specified in a harmonised way.
The first point is where I see we are going a bit in cycles. We had two calls
for interest and two BOFs for mission planning. The report from the two calls
for interest, which was also published as a paper in the SpaceOps high-lights
clearly the user need for defining mission planning services. At the BOF in
London strong concerns were raised to ensure that whatever we do, at the end
it shall be possible to exchange the mission planning information without
being forced to use a service framework and by means of simple file exchange.
We believe these two objectives were both valid and both supported by the
community. It was therefore agreed to first concentrate on defining an
information model and in a second step (not third or forth) to define the
services.
We have respected these two objectives and the order of the priority in the
charter and the white paper. Btw, the scope section of the white book is a
copy and paste from the charter, which you said is ok in the previous note.
When defining the information model it is important to be "service aware"
this has little impact on the final results for those who do not care about
services but want to simply exchange the information, where as not doing it
has a considerable impact for the second step. In effect the final result of
the work will be a formal data or information model specified as XML schema,
which does not impose the use of MO Framework. Organisations who do not want
to use service, will have a concrete data model for planning requests, plans,
schadule and other involved entities. They can write concrete XML documents
or JASON or binary messages compliant to this model and exchange it via
files.
However within MOIMS, we want to ensure that there is a consistent
information model that establishes relations between the entities defined for
different domains (e.g. Actions, Alerts, Events, Checks, Parameters,
Aggregations and Planning Request, Plan, Schedule, PlanningRequestStatus,
etc.).
I believe the use of CSTS for Ground Stations and use of MO Framework for
things outside the Ground stations reflects the "cut" between ESA , NASA and
other agencies which was agreed during the CCSDS Meetings in London.
Now, I am afraid that in all this discussion, the practical impact may seem
larger than it actually is so that we are having a discussion at conceptual
level rather than on practical level. That is why I would like to highlight
again that defining the information model as suggested by the concept paper
and the charter would not have practical disadvantages for people who do not
care about services.
In view of above, I suggest that I update the paper to clarify point (2) and
accepting your text modifications. For point 1, I would add text that
explains that in practical terms defining the information model while being
"service aware" would mean separation of data from meta-data in different
sections of the document and using certain namespaces and ensuring
consistency with the already defined information model of other MOIMS areas.
Would this be an acceptable approach?
Regards
Mehran
On 13 May 2015, at 00:49, Shames, Peter M (312B)
<peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>> wrote:
Hi Mehran,
This is much improved, but I do still have two major issues.
What I got from the community was that they would value having a clear set
of standards that they can use with their existing planning systems. This
charter says "yes, we'll give you an info model for files, but we are really
going to require the use of the MO Framework, even to define these forms."
While I recognize the desireability of this kind of approach for any
community that has chosen to adopt the MO Framework, I doubt that anyone who
has not made that choice will find this to be attractive. I think you really
need to carefully consider what these specs must do for the users, and as a
second or third level consideration map them into the MO, not the other way
around.
Along those same lines, this white paper seems to make the foregone
conclusion that XML is the only way to exchange these data (and that XML is
be derived from the MO model, see issue 1). XML is certainly a strong
possibility, but there are also other very effective approaches for portably
defining data structures, such as ASN.1, BNF, or even JSON, etc that are
equally viable. ASN.1, for instance, has direct translations into XML, JSON,
and even compact binary forms. I think you should leave that door more open
for the planning community to decide what they think is most viable in the
long run.
There are a few other minor items marked in the text, but there are the two
big ones I identified.
Regards, Peter
From: "Mehran.Sarkarati at esa.int<mailto:Mehran.Sarkarati at esa.int>" <Mehran.Sarkarati at esa.int<mailto:Mehran.Sarkarati at esa.int>>
Date: Tuesday, May 12, 2015 at 12:20 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Cc: Brigitte Behal <Brigitte.Behal at cnes.fr<mailto:Brigitte.Behal at cnes.fr>>, Dan Smith
<danford.s.smith at nasa.gov<mailto:danford.s.smith at nasa.gov>>, Mario Merri <Mario.Merri at esa.int<mailto:Mario.Merri at esa.int>>, Nestor Peccia
<Nestor.Peccia at esa.int<mailto:Nestor.Peccia at esa.int>>, Roger Thompson <Roger.Thompson at scisys.co.uk<mailto:Roger.Thompson at scisys.co.uk>>
Subject: Re: Updated MO Concept Paper
Peter,
I did send a normal .docx document. No idea what went wrong.
Second try.
I am attaching both .doc and .pdf versions.
Regards
Mehran
Dr. Mehran Sarkarati
Head Application And Special Projects Section
ESA - European Space Agency
ESOC / HSO-GDA
Robert-Bosch-Str. 5
64293 Darmstadt
Germany
Tel: +49 6151 903225
Email: mehran.sarkarati at esa.int<mailto:mehran.sarkarati at esa.int>
From: "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
To: "Mehran.Sarkarati at esa.int<mailto:Mehran.Sarkarati at esa.int>" <Mehran.Sarkarati at esa.int<mailto:Mehran.Sarkarati at esa.int>>,
"Nestor.Peccia at esa.int<mailto:Nestor.Peccia at esa.int>" <Nestor.Peccia at esa.int<mailto:Nestor.Peccia at esa.int>>, "Mario.Merri at esa.int<mailto:Mario.Merri at esa.int>"
<Mario.Merri at esa.int<mailto:Mario.Merri at esa.int>>, "brigitte.behal at cnes.fr<mailto:brigitte.behal at cnes.fr>" <brigitte.behal at cnes.fr<mailto:brigitte.behal at cnes.fr>>,
Cc: Roger Thompson <Roger.Thompson at scisys.co.uk<mailto:Roger.Thompson at scisys.co.uk>>,
"danford.s.smith at nasa.gov<mailto:danford.s.smith at nasa.gov>" <danford.s.smith at nasa.gov<mailto:danford.s.smith at nasa.gov>>
Date: 12/05/2015 17:09
Subject: Re: Updated MO Concept Paper
Mehran,
The file that arrived on my end had a suffix of ".doc.hqx". My system has
no idea what to do with this sort of file. Please resend in a normal .doc
or .pdf form.
Thanks, Peter
From: "Mehran.Sarkarati at esa.int<mailto:Mehran.Sarkarati at esa.int>" <Mehran.Sarkarati at esa.int<mailto:Mehran.Sarkarati at esa.int>>
Date: Tuesday, May 12, 2015 at 6:54 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, Nestor Peccia
<Nestor.Peccia at esa.int<mailto:Nestor.Peccia at esa.int>>, Mario Merri <Mario.Merri at esa.int<mailto:Mario.Merri at esa.int>>, Brigitte Behal
<Brigitte.Behal at cnes.fr<mailto:Brigitte.Behal at cnes.fr>>
Cc: Roger Thompson <Roger.Thompson at scisys.co.uk<mailto:Roger.Thompson at scisys.co.uk>>, Dan Smith
<danford.s.smith at nasa.gov<mailto:danford.s.smith at nasa.gov>>
Subject: Updated MO Concept Paper
Dear Peter,
Roger and I have made an effort to update the concept paper, taking your
comments into account.
We have approached it with an open mind and have removed the unnecessary
references and background material related to MO.
Please have a look and see if this updated version is in line with your
expectations and fulfils your raised condition.
In view of the upcoming CMC meeting on 18 May, I would appreciate a quick
feedback.
Kind Regards
Mehran
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.
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. - CCSDS
Mission Planning Services Concept Paper v4_Clean copy-SEA.pdf
<CCSDS Mission Planning Services Concept Paper v4_Clean copy-SEA.pdf>
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.
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.
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/cmc/attachments/20150707/91944fe7/attachment.html>
More information about the CMC
mailing list