[CESG] [CMC] CESG Report to CMC

Shames, Peter M (312B) peter.m.shames at jpl.nasa.gov
Thu Jun 8 18:39:03 UTC 2017


Hi Nestor,

Answers to Jean-Marc questions are in-line, below.  I'll submit the updated pages once I have reviewed the other CMC inputs.

Thanks, Peter


From: CESG <cesg-bounces at mailman.ccsds.org> on behalf of Nestor Peccia <Nestor.Peccia at esa.int>
Date: Thursday, June 8, 2017 at 10:14 AM
To: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>
Subject: [CESG] [CMC] CESG Report to CMC

Please either prepare response or update your Area report


CNES questions / comments:

Page 9 / 120 :     Which rationale for restarting IPSec testings ?
<< The IPSec testing was incomplete. As a result the YB report of the testing was not adequate for approval.  Thus the tests must actually be run to the appropriate conclusion. >>
                                Interaction with IOAG is not clear: IOAG expresses what they need in SC’s, not what CCSDS want they use. Security is in all IOAG infrastructures and projects.  Peter to clarify
<< Both of the IOAG Service Catalogs, #1 and #2 are almost totally silent on security.  They do not even mention the topc, except for "bundle security" in SC#2.  Neither are authentication nor encryption addressed.  The SecWG was merely pointing this out.  It is true that most of the CCSDS services do have an access controlled mode, but the IOAG SC are silent on the subject.  >>

Page 13/120 :     What are the issues with DAI and MPS WGs ? They have approved projects and may not be in “early planning” depending what was discussed.   Peter to clarify
<< The draft DAI materials contain a great number of ambiguities and there is a concern that the proposed scope of work greatly exceeds the available resources.  This does not seem like a recipe for success.  Furthermore, the proposed work is not really supported by the DAI charter, except in that it has a very vaguely worded clause "DAI WG will address all areas of Archive data formats, functions, and operations".  There is no stated goal in the Charter that covers this extensive propsed body of technical work.  This was discussed with the DAI directly and a presentation describing the analysis of the draft approach was prepared by SEA SAWG and presented to the DAI WG.  This can be provided if desired (attached here).>>
<< The MPS WG is proposing to develop a single specification that combines, in one document, both a set of fully interoperable data format standards, not unlike what the MOIMS Nav WG and CSS SM WG has produced, and also a set of service specifications.  The body of CCSDS standards (and Internet standards, among others) are formulated with a focus on one topic at a time.  The rationale is that individual standards, focused on a single "layer", may more easily be adopted and re-used, where a combined standard does not have those properties.  Granted that an understanding of the abstract interactions, and even services, that a data format will be used for is useful for understanding, but a formal service interface, ala CSS SLE, is a much more significant undertaking.
The SEA recommendation is that these be produced as two separate, but related, specifications in alignment with usual CCSDS practices. >>

Page 14/120 :     On resolution 1 and SCID document, 320x0p6.1, ESA RIDs are mentioned ; CNES never got any response or disposition of their RIDs. To be clarified.  Peter to clarify
<< My apologies.  While we did review the CNES RIDs they were left off this slide.  This is a proposed resolution and it has not yet been fully processed.  When it is the CNES and ESA RIDs will all be addressed. >>

Pages 17~20 :     SCID document, 320x0p6.1 appears on 3 pages. Similar for CCSDS Application & Support Architecture… Peter to clarify
<< It appears on pg 17, under "Exec Summary".  It appears on pg 18 under "Approved Project Status" for the SEA SA.  It appears, in error, on pg 19.  This will be fixed.  >>

Page 33/120 :     Is that a question to IOAG (via liaison) or within the WG ? The question of IOAG priority on these services should be raised as well, together with the question of how the IOAG priority
will be taken into account, if very high or if very low.     Erik to clarify, but the full IOAG ./ ICPA report will be put together by CESG Chair. This was my fault for not having taken out the chart and include it in the IOAG report. I will rearrange the charts in the next report update
Page 60/120 :     “formalize the WG membership” to be explained = what is expected from CMC is not clear.   Mario to clarify
Page 101/120 :   Are these statements about IOAG interfaces also part of the liaison report ? Gippo to clarify  but the full IOAG ./ ICPA report will be put together by CESG Chair. This was my fault for not having taken out the chart and include it in the IOAG report. I will rearrange the charts in the next report update

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/cesg/attachments/20170608/3753c043/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DAI v4 Concept Analysis - SEA for CESG 21Apr17.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 1426262 bytes
Desc: DAI v4 Concept Analysis - SEA for CESG 21Apr17.pptx
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20170608/3753c043/attachment.pptx>


More information about the CESG mailing list