[CMC] [Cesg-all] Results of CESG Polls closing 23 April 2015

Mario.Merri at esa.int Mario.Merri at esa.int
Tue Jul 7 16:48:40 UTC 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>
To:     "Mario.Merri at esa.int" <Mario.Merri at esa.int>, 
Cc:     "brigitte.behal at cnes.fr" <brigitte.behal at cnes.fr>, 
"danford.s.smith at nasa.gov" <danford.s.smith at nasa.gov>, 
"Mehran.Sarkarati at esa.int" <Mehran.Sarkarati at esa.int>, 
"Nestor.Peccia at esa.int" <Nestor.Peccia at esa.int>, Roger Thompson 
<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>
Date: Tuesday, May 19, 2015 at 10:03 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Brigitte Behal <Brigitte.Behal at cnes.fr>, Dan Smith <
danford.s.smith at nasa.gov>, "Mehran.Sarkarati at esa.int" <
Mehran.Sarkarati at esa.int>, Nestor Peccia <Nestor.Peccia at esa.int>, Roger 
Thompson <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>
To:        "Mehran.Sarkarati at esa.int" <Mehran.Sarkarati at esa.int>, 
Cc:        "brigitte.behal at cnes.fr" <brigitte.behal at cnes.fr>, "
danford.s.smith at nasa.gov" <danford.s.smith at nasa.gov>, "Mario.Merri at esa.int
" <Mario.Merri at esa.int>, "Nestor.Peccia at esa.int" <Nestor.Peccia at esa.int>, 
"Roger Thompson" <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" <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> 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" <Mehran.Sarkarati at esa.int>
Date: Tuesday, May 12, 2015 at 12:20 PM 
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Brigitte Behal <Brigitte.Behal at cnes.fr>, Dan Smith
<danford.s.smith at nasa.gov>, Mario Merri <Mario.Merri at esa.int>, Nestor 
Peccia 
<Nestor.Peccia at esa.int>, Roger Thompson <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



From:        "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>
To:        "Mehran.Sarkarati at esa.int" <Mehran.Sarkarati at esa.int>,
"Nestor.Peccia at esa.int" <Nestor.Peccia at esa.int>, "Mario.Merri at esa.int"
<Mario.Merri at esa.int>, "brigitte.behal at cnes.fr" <brigitte.behal at cnes.fr>,
Cc:        Roger Thompson <Roger.Thompson at scisys.co.uk>,
"danford.s.smith at nasa.gov" <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" <Mehran.Sarkarati at esa.int>
Date: Tuesday, May 12, 2015 at 6:54 AM 
To: Peter Shames <peter.m.shames at jpl.nasa.gov>, Nestor Peccia
<Nestor.Peccia at esa.int>, Mario Merri <Mario.Merri at esa.int>, Brigitte Behal 

<Brigitte.Behal at cnes.fr>
Cc: Roger Thompson <Roger.Thompson at scisys.co.uk>, Dan Smith
<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/336db0db/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CCSDS Mission Planning Services Concept Paper	v4_Clean.pdf
Type: application/octet-stream
Size: 519991 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/cmc/attachments/20150707/336db0db/attachment.obj>


More information about the CMC mailing list