[CMC] CESG responses to CMC comments

[Nestor.Peccia at esa.int]

Dear CMC

Please find below the CESG responses to Osvaldo and Jean Marc's comments

Osvaldo's comments
Page 3: 
I would delete the SIS voice here, the problem is the secretariat, not the 
WG. I would not blame the secretariat for the delays, there were contract 
problems and some inconsistencies and 3 years delay is a little bit too 
much, but if the WG is accepting that, we should not complain against the 
secretariat, they are doing a great job. 
CESG Chair response: Not accepted. CESG Chair will explain the rationale 
when presenting
Page 8: 
What are the ?data quality? issues mentioned
SEA AD response:  The "data quality" issues are minor, but potentially 
annoying, inaccuracies that existed in the source data and were carried 
into the new registries.  Examples are: 
in Contacts: "first name" and "last name" are identified in the new 
database to allow sorting on last name.  In much of the source data there 
is just a Name field, so this first / last name distinction must be 
handled by editing the data.
In Organizations:  Many of the entries (which came from at least three 
different sources) are missing information such as Country, URL, 
abbreviation, address, and roles.
Since the original sources did not have these data fields nothing is lost 
in terms of "quality", but it will be important to remedy this if the new 
registries are to be as useful as they can be.  SEA SSG proposes making 
these new registries "official" and dealing with these quality issues 
after the fact as a "clean up" exercise.
Page 26: 
Are there any proposals from the WG/agencies for new chair/deputy?
CSS Area response: ESA has nominated Holger Driehahn to chair the CSTS 
working group.  The current CNES deputy chair as indicated that he plans 
to retire by spring of next year. There is currently no nominee from any 
agency with regard to the deputy chair position.
CESG Chair addition: CSS AD will ask soon the CMC delegates for potential 
nominations.
Page 33: 
Is that a question to IOAG or within the WG. What kind of file service is 
planned by the area.
CSS Area response: it is a question to CMC. Does the CMC wish to expend 
resources developing a standardized recommendation for these kind of 
services for interoperability? Currently the only recommendation that the 
area is working on is the Generic Terrestrial File Transfer.  This is 
simply an interoperable standardized file transfer from point A to point 
B. No further services envisioned. The description of the services 
indicated here implies a further processing such as taking the transferred 
file and then transforming it into a CFDP file for uplink assuming a CFDP 
endpoint at the ground station etc.
CESG Chair addition: Chart will be transferred to the IOAG/CMC item 
presentation
Page 36: 
Are the resources for the second CFDP prototype still missing? Comments on 
page 39/49
SIS AD response: Yes. ESA can not commit the granted resources in 2017. 
2018 is TBD
Page 60: 
The WG requests the CCSDS management to formalize the WG membership. Is 
there any proposal, what a formalized membership could be? 
MOIMS AD response: This point is covered by the proposed updates to the 
YB. AD will delete it from the presentation.
Page 63: 
What happened to the Perturbation Message, which was a draft book and 
disappeared?
MOIMS AD response: The Spacecraft Perturbation Message project was deleted 
upon request by the NAV WG of 13Jan17. This decision was based on (a) the 
fact that the technical material that was once targeted for the SPM is now 
being covered in some of the other Navigation WG documents, and (b) 
leaving it in the NAV 5 Year Plan and Draft Project list creates a false 
impression.
Page 66: 
Are there any priority issues coming from the work of the IOAG MOSSG final 
report?
MOIMS AD response: So far the MOSSG provided only informal information to 
the SM&C WG. It is understood that the CCSDS shall consider in its 
planning only formal priorities coming directly from the IOAG. This has 
not yet happened.
Jean Marc's comments
Page 5 / 120 : 
should read Spring 2017.
CESG Chair response: Updated
Page 9 / 120 : 
Which rationale for restarting IPSec testings ? 
SEA AD response: 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.
SEA AD response: 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.
The following are the SEA AD's responses
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.
CESG Chair's view: 
DAI WG to be discussed under separate Agenda item, presenting the CESG 
agreed text
MPS BB non-consensus will be presented at the CMC meeting by CESG Chair. 
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.
SEA AD response: 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?
SEA AD response: 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.
CSS Area response: it is a question to CMC. Does the CMC wish to expend 
resources developing a standardized recommendation for these kind of 
services for interoperability? Currently the only recommendation that the 
area is working on is the Generic Terrestrial File Transfer.  This is 
simply an interoperable standardized file transfer from point A to point 
B. No further services envisioned. The description of the services 
indicated here implies a further processing such as taking the transferred 
file and then transforming it into a CFDP file for uplink assuming a CFDP 
endpoint at the ground station etc.
CESG Chair addition: Chart will be transferred to the IOAG/CMC item 
presentation
Page 60/120 : 
 ?formalize the WG membership? to be explained = what is expected from CMC 
is not clear.
MOIMS AD response: This point is covered by the proposed updates to the 
YB. AD will delete it from the presentation
Page 101/120 : 
Are these statements about IOAG interfaces also part of the liaison report 
?
CESG Chair response: Chart to be taken out from the SLS Area report and to 
be included in the IOAG/ICPA agenda item
Page 117/120 : 
the yellow frame with agency participation would better fit the next page.
CESG Chair response: Done
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/20170609/9a5a3a74/attachment.html>