[CESG] CESG-P-2023-02-002 Approval to publish CCSDS 922.27-O-1, Cross Support Transfer Service—Return CFDP PDU Service (Orange Book, Issue 1)

[CCSDS Secretariat]

Dear CESG Members,

Conditions for approval of CCSDS 922.27-O-1, Cross Support Transfer Service—Return CFDP PDU Service (Orange Book, Issue 1) have either been explicitly disposed to the satisfaction of the AD(s) who voted to approve with conditions or have been deemed disposed due to lack of response within the period of time allowed in CCSDS A02.1-Y-4, Organization and Processes for the Consultative Committee for Space Data Systems. The Secretariat will now proceed with CMC polling to authorize publication.
-------------- next part --------------
From:	Holger Dreihahn <Holger.Dreihahn at esa.int>
Sent:	Friday, April 14, 2023 4:18 AM
To:	Thomas Gannett
Subject:	FW: [EXTERNAL] FW: CESG-P-2023-02-002 Approval to publish CCSDS 922.27-O-1, 
Cross Support Transfer Service—Return CFDP PDU Service (Orange Book, Issue 1)
Attachments:	922x27o0_CESG_Approval-SEA 21Mar23.doc

Dear Tom,
See below. I fail to get any feedback from Tomaso, one of the two ADs raising conditions. With Peter we 
reached a ‘success’ status, after a very good discussion. Anything we can do to get feedback from an 
AD?

Best regards,
Holger

From: Holger Dreihahn <Holger.Dreihahn at esa.int> 
Date: Tuesday, 28. March 2023 at 08:44 
To: Tomaso.deCola at dlr.de <Tomaso.deCola at dlr.de> 
Subject: FW: [EXTERNAL] FW: CESG-P-2023-02-002 Approval to publish CCSDS 922.27-O-1, 
Cross Support Transfer Service—Return CFDP PDU Service (Orange Book, Issue 1)
Hello Tomaso,
Any news on the subject?
 
Best regards,
Holger
 
From: Holger Dreihahn <Holger.Dreihahn at esa.int> 
Date: Wednesday, 22. March 2023 at 16:27 
To: "Tomaso.deCola at dlr.de" <Tomaso.deCola at dlr.de> 
Subject: FW: [EXTERNAL] FW: CESG-P-2023-02-002 Approval to publish CCSDS 922.27-O-1, 
Cross Support Transfer Service—Return CFDP PDU Service (Orange Book, Issue 1)
 
Hello Tomaso,
I hope you are doing fine. Please find attached an updated RCFDP book, which Felix and me have 
iterated quite a bit with Peter to improve the conceptual description, which was also your point. Now 
that this is improved and Peter is happy I would ask you to have a look. Especially section 2 has been 
reworked quite a bit and hopefully addresses also your point of not being clear enough (which was true).
 
For your comment of the ASN.1 annexes I added pointers to the underlying CSTS Service Specification 
Framework, which explain what each service shall specify here in terms of identifiers (OIDs) and types. 
Again I hope that makes it more clear.
 
Let me know if that is OK for you or if you have further comments. In case of interest, you have the 
email exchange with Peter below; also the document has the changes tracked and the comments from 
Peter.
 
Best regards,
Holger
 
From: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov> 
Date: Tuesday, 21. March 2023 at 17:43 
To: Holger Dreihahn <Holger.Dreihahn at esa.int>, Felix Flentge <Felix.Flentge at esa.int> 
Subject: Re: [EXTERNAL] FW: CESG-P-2023-02-002 Approval to publish CCSDS 922.27-O-1, Cross 
Support Transfer Service—Return CFDP PDU Service (Orange Book, Issue 1)
 
Dear Holger,
 
I think we are at a point where we can declare ”Success”.   I like the revised diagrams and think they are 
now clear enough.  I made a few minor changes to the language in those two sections for clarity and 
fixed a couple of typos in the attached update. 
 
I can understand that those CFDP state charts are a little hard to deal with.  I offered them up if they 
might be of use.  They were already published in the CFDP Green Book, but they might usefully find a 
home in an annex of a future update of of the CFDP BB, if there is one.
 
I am not sure what you mean by “Industry, currently analyzing the RCFP White Book”.  Were you 
indicating that Industry had been given access to the RCFDP-CSTS White Book and that they had 
identified issues?  If so, we can hope that these edits will fix those problems.
 
Best regards, Peter
 
 
From: Holger Dreihahn <Holger.Dreihahn at esa.int> 
Date: Tuesday, March 21, 2023 at 2:49 AM 
To: Peter Shames <peter.m.shames at jpl.nasa.gov>, Felix Flentge <Felix.Flentge at esa.int> 
Subject: Re: [EXTERNAL] FW: CESG-P-2023-02-002 Approval to publish CCSDS 922.27-O-1, Cross 
Support Transfer Service—Return CFDP PDU Service (Orange Book, Issue 1)
 
Dear Peter,
Super, looks we are converging. Please find attached the latest update, showing the ‘e.g. SFTP’ transfer 
of the on-ground reconstructed files to File Users. This is indeed really required for consistency. We 
discussed a bit how to include the state diagrams and they are really useful. However, we did not 
include them now in the RCFDP book, actually they look like a candidate for the CFDP book itself. 
Actually we did not find a visually compelling way of overlaying the diagrams with the CFDP File 
Reconstruction and the CFDP Protocol State machine. I hope that is OK.
 
Other than that we really believe that also Industry, currently analyzing the RCFP White Book will benefit 
from the improved book. We actually already saw misunderstandings, we did not expect. Hopefully and 
thanks to your constructive review, that will improve.
 
We also need to seek Tomaso’s agreement, but I think he will appreciate the improved description, 
which was also his concern.
 
Best regards,
Holger
 
From: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov> 
Date: Monday, 20. March 2023 at 20:59 
To: Holger Dreihahn <Holger.Dreihahn at esa.int>, Felix Flentge <Felix.Flentge at esa.int> 
Subject: Re: [EXTERNAL] FW: CESG-P-2023-02-002 Approval to publish CCSDS 922.27-O-1, Cross 
Support Transfer Service—Return CFDP PDU Service (Orange Book, Issue 1)
 
Hi Holger and Felix,
 
This is great.  I think we are just about there.  After thinking about your edits and comments I believe 
that I now get how you have constructed the Fig 2-1 architecture.  I have some edits to suggest to make 
it crystal clear (at least in my mind).  See attached PPT and PDF.
 
And, having thought about Fig 2-1, and what was missing, I think that the SFTP protocol (or whatever) 
and final file delivery to the “EUN File User” would be useful to add to Fig 2-2 as well.  Then these figures 
would be symmetrical.
 
It also occurs to me that relating these split instances of CFDP functions to the CFDP State Diagram 
might be of use.  When I was working the EEIS issues for CFDP on Europa Clipper the attached collection 
of diagrams from the CFDP Green Book, CCSDS 720.2-G-3, proved very useful.  I’m attaching them here 
in case they are of value to you.  I was imagining overlaying dashed lines showing the “split off” parts of 
the protocol for these different deployment approaches.
 
At any event, once you are happy with the result of this discussion finish it up and let’s get it published.
 
Best regards, Peter
 
 
From: Holger Dreihahn <Holger.Dreihahn at esa.int> 
Date: Monday, March 20, 2023 at 5:39 AM 
To: Peter Shames <peter.m.shames at jpl.nasa.gov>, Felix Flentge <Felix.Flentge at esa.int> 
Subject: Re: [EXTERNAL] FW: CESG-P-2023-02-002 Approval to publish CCSDS 922.27-O-1, Cross 
Support Transfer Service—Return CFDP PDU Service (Orange Book, Issue 1)
 
Dear Peter,
Thanks again and true, this makes the book better. Please find attached an updated version of the 
RCFDP Book. The main update is for figure 2-1, it has now labels similar to figure 2-2 and shows also 
where the files are on-board and on-ground – granted, that may be of interest for file delivery service. 
The only thing which may still be controversial is the box now labelled ‘CFDP PDU Relay’ in figure 2-1. 
You called it an instance of a CFDP Protocol State Machine, however, we see it as a function getting 
CFDP PDUs (the ACKs and NACKs) from ESLT / RCFDP Provider, wrapping it as appropriate for the 
spacecraft into packets and TC frames, applying optionally encryption / authentication, code the whole 
thing as a CLTU and send it by means of SLE CLTU to the ESLT. The ESLT would finally uplink to the 
spacecraft. But now the labels should show that. This CFDP PDU relay function would be typically a part 
of a mission control system, as it may need to multiplex with other TCs. However, the CFDP PDU relay 
function does not need to run any CFP state machine, that is purely done by the CFDP entity sitting in 
ESLT (figure 2-1). A similar architecture we use for the Euclid spacecraft hopefully launching soon.
 
Some more answers below in the text.
 
Best regards,
Holger
 
 
From: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov> 
Date: Friday, 17. March 2023 at 17:52 
To: Felix Flentge <Felix.Flentge at esa.int>, Holger Dreihahn <Holger.Dreihahn at esa.int> 
Subject: Re: [EXTERNAL] FW: CESG-P-2023-02-002 Approval to publish CCSDS 922.27-O-1, Cross 
Support Transfer Service—Return CFDP PDU Service (Orange Book, Issue 1)
 
Hi Felix and Holger,
 
Glad this is working out as well as it is.  I think the document will be more useful after these 
changes.  What you guys have constructed is a useful formalism for what a lot of missions seem to want 
to hack.  Your motivation is to handle the bandwidth disparity, which is also often true for others.  But 
many missions also seem to be motivated by the desire to have the EUN / MOC in charge of uplink and 
retransmission decisions.  This architecture provides both.  I know that is not a motivation of yours, but 
it is a useful side-effect.
HD: Actually the latter (MCS in control and performing encryption / auth) is not only a side effect. Also 
for our Sentinel missions, the keys shall not be given to (external) ground stations.
 
I’d still like you to insert some labels on fig 2-1, parallel to what you did on fig 2-2.  Just looking at the 
figure it is not clear (until you read the following text) that what is flowing between the ESLT and the 
EUN is only the ACK, NAK, and report traffic, and that the blank box in the EUN is really an instance of a 
“CFDP Protocol State Machine”.  Labeling these boxes and flows, as in fig 2-2, would make this more 
clear.
HD: Labels added.
 
On the “CFDP destination entity ID”, thanks.  I had forgotten that that was a CFDP protocol feature.  It’s 
been a few years since I read that particular spec.  That makes more sense.  Maybe add a sentence that 
just clarifies that where the topic first shows up?  That is essentially using a field inside the CFDP 
Protocol to guide behavior of the RCFDP-CSTS protocol that carries these PDUs.  That is in some senses a 
“layer violation” because it requires looking into the PDUs to determine what to do with them, but if you 
treat it as a managed parameter and describe it in a simple sentence that should be clear enough.  I’d 
not request anything more elaborate.
HD: The explanation that the CFDP destination entity is part of the CFDP PDU header has been added, 
that should improve readability.
 
As for the KPLO LTP issue and how it might relate to this spec, I can only provide the attached PPT file.  It 
is incomplete and inaccurate, as I am sure you will see (for instance, there are SLE provision elements 
but no SLE user elements), but the logic behind it is essentially the same as for the “mission wants to be 
in control” case of your RCFDP example.  In this case you might call it an RLTP-CSTS service because it is 
LTP that is being split between the DSN and the MOC.  As I understand it the big motivator for KPLO was 
that they wanted to close the LTP transfer link in the DSN, and to use secure LTP, but did not want to 
have to give DSN the keys.  So they sent the control traffic to the KPLO MOC, generated the secured LTP 
PDUs in the MOC, and shipped them back to the DSN and the mission using F-CLTU.  You have to “read 
between the lines” in the protocol diagrams because some elements are missing. 
HD: Very similar motivation. For our case the keys shall be only at mission control. Also: F-CLTU 
supports only one source of commanding (unless you do very ugly things like ‘spare CLTUs’ to be filled 
at the station, I am not kidding, has been proposed), so if you want to do traditional commanding 
while having LTP based downlinks, what do you do? CSTS Forward Frame would be a way to have 
more than one commanding source.
 
My thinking is that since the CFDP protocol processing is really outside of the RCFDP-CSTS transport 
spec, that it could serve just as well for handling this sort of split delivery for LTP too.  LTP is, after all, 
essentially the reliable (but not in order) retransmission parts of CFDP extracted and packaged for 
reliable DTN over a single space link “hop”.  The current CFDP over DTN discussions, as I understand 
them, are to run unreliable, Class 1, CFDP over DTN over LTP.  This is all, in my mind, a deconstruction of 
CFDP Class 3 / 4 into a set of separate specs, but this is a whole separate discussion.
HD: We want to have a service specification, which allows an external ground station provider to 
realize an RCFDP provider w/o being a CFDP expert. Since the RCFDP provider needs to know the 
format of CFDP PDUs (but not the CFDP state machines) to perform the filtering according to CFDP 
destination entity ID and finally the CFDP reduction of CFDP File Data PDUs, we decided to design the 
service CFDP specific. It is of course possible to design a general PDU forwarding service, but then you 
need to find ways to describe protocol specific handling.
 
Back on the “how does LTP relate to CFDP in the RCFDP-CSTS example.  If the CFDP entities, “full CFDP 
engine”, “CFDP Protocol State Machine”, and “CFDP File Reconstruction” were replaced by “full LTP 
engine”, “LTP Protocol State Machine”, and “LTP File Reconstruction” entities, wouldn’t this also serve 
to distribute LTP, deal with bandwidth limitations, and put retransmission control and uplink encryption 
into the EUN?  I suspect that the only parts of the DCFDP-CSTS spec that would need to be modified 
would be the parts that examine the CFDP PDUs and make “reduction”, processing and routing 
decisions. The whole rest of the transport is involved in shipping the resulting PDUs and is probably (in 
my wild imagining) PDU structure and contents agnostic.
HD: I think Felix can provide more thoughts on this, but basically LTP works on blocks, not files. In 
general when you have LTP, we believe you can design ‘cleaner’ architectures. However for LTP (as for 
every ARQ mechanism), you need a way to talk to the spacecraft to close the loop. Our hope here is 
that e.g. by using a separate channel (optical: beacon, FR: separate TC VC or physical channel), the 
station would be allowed to directly send protocol information to the spacecraft, which are then 
terminated e.g. in the transponder, but never reach the onboard computer (as such they are in a way 
not real commands). Especially when operating at very high rates, the additional delay imposed by 
the MCS detour can be problematic. And again, the architecture is not really nice; there are more 
dependencies and interfaces than there should be.
 
I may be off-base here.  Sometimes my imagination gets the better of me.  Does that “can we do this 
too?” question make sense now?
HD: It does, but as described above, we wanted a CFDP specific service to be implementable by non-
CFDP experts. 
 
Cheers, Peter
 
 
 
 
From: Felix Flentge <Felix.Flentge at esa.int> 
Date: Friday, March 17, 2023 at 12:16 AM 
To: Peter Shames <peter.m.shames at jpl.nasa.gov>, Holger Dreihahn 
<Holger.Dreihahn at esa.int> 
Subject: RE: [EXTERNAL] FW: CESG-P-2023-02-002 Approval to publish CCSDS 922.27-O-1, Cross 
Support Transfer Service—Return CFDP PDU Service (Orange Book, Issue 1)
 
Thanks a lot, Peter,
 
From my point of view your updates in the text are fine and should improve the understanding.
 
I have replied to your two comments, please have a look.
 
Regarding the KPLO demo, I never fully understood how they deal with LTP on the uplink. My impression 
is that it is similar to what we do in the contained scenario with LTP processing at one of the DTN nodes 
(I assume the first) and then LTP segments for the uplink being send over TCP and UDP over some hops 
to be eventually included in the uplink and sent to the station via F-CLTU. We have done something 
similar for the Euclid mission and CFDP Class 2 where we simply ‘mis-‘used SLE-RCF to provide CFDP for 
the uplink from the station to the mission control system for the uplink (now, we would be able to use 
R-CFDP full mode for that). Having said this, in an ideal scenario, we would prefer to have direct protocol 
closure from the station with using CSTS-FF to access the uplink
 
Regards,
Felix
 
From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>  
Sent: 17 March 2023 01:31 
To: Holger Dreihahn <Holger.Dreihahn at esa.int> 
Cc: Felix Flentge <Felix.Flentge at esa.int> 
Subject: Re: [EXTERNAL] FW: CESG-P-2023-02-002 Approval to publish CCSDS 922.27-O-1, Cross 
Support Transfer Service—Return CFDP PDU Service (Orange Book, Issue 1)
 
Hi Holger and Felix,
 
Working with you guys on this has been great and I am glad you think it is worthwhile too.  The 
way I usually deal with that “if someone just looks long enough at something, the obvious is not 
apparent anymore” is to put things aside after writing, but before sending.  It’s a trick.  “Fresh 
eyes” will always see things differently.
 
I think you made most of the needed improvements, but there were still some parts that I 
thought could be made even more clear.  Instead of just sending notes back and forth I just 
edited the text, with track changes left on.  I hope you don’t mind that rather “forward” 
behavior.
 
Take a look as see if I mis-understood or misrepresented anything.  I know that you guys know 
how this works.  All of this extra stuff was to make sure that if someone else wanted to try this 
out that they would really understand what was being done.  
 
BTW – the Koreans did something like this to get LTP running for their DTN implementation.  I 
wonder if essentially the same approach would work for that?
 
Cheers, Peter
 
 
From: Holger Dreihahn <Holger.Dreihahn at esa.int> 
Date: Thursday, March 16, 2023 at 6:28 AM 
To: Peter Shames <peter.m.shames at jpl.nasa.gov> 
Cc: Felix Flentge <Felix.Flentge at esa.int> 
Subject: Re: [EXTERNAL] FW: CESG-P-2023-02-002 Approval to publish CCSDS 922.27-O-
1, Cross Support Transfer Service—Return CFDP PDU Service (Orange Book, Issue 1)
 
Dear Peter,
We made an effort to respond to your comments and on-board them all (ok, most of them). 
Also the scribbled figure should be reflected (thanks for that). I think this review proves, that if 
somebody (in this case Felix and me) just looks long enough at something, the obvious is not 
apparent anymore. 
 
To have things together I copied your comments from the PDF to Word, I hope I got them all. 
The ASN.1 appendices already give a pointer to the CSTS Service Specification Framework 
mandating and explaining the ANS.1 definitions, I hope that is OK. It is a response to Tomaso’s 
comments.
 
Let us know what you think about the updates and thanks again for your effort. We really see 
improvements of the document.
 
Best regards,
Holger
 
From: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov> 
Date: Wednesday, 15. March 2023 at 01:48 
To: Holger Dreihahn <Holger.Dreihahn at esa.int> 
Cc: Felix Flentge <Felix.Flentge at esa.int> 
Subject: Re: [EXTERNAL] FW: CESG-P-2023-02-002 Approval to publish CCSDS 922.27-O-
1, Cross Support Transfer Service—Return CFDP PDU Service (Orange Book, Issue 1)
 
Dear Holger,
 
It is always my intent to make the books I review better, but I do realize that it is not always 
seen as a positive contribution.  So I really appreciate you acknowledging that.  
 
The diagram you sent is improved since it shows multiple ESLTs and also the separate full and 
reduced flows.  But it still is not fully satisfactory for me.  I scribbled on the figure and have 
attached it here as a PPT file.  Maybe we can use this to get clear what it is that you have really 
designed.
 
As you say in your note “The RCFDP service now allows you to realize a terrestrial distribution of 
that CFDP entity”.  I get that RCFDP basically just transports CFDP PDUs (at least I think that is 
the case).  Some outside of that transport protocol (and the reduction logic) there must be some 
other elements that handle the two parts of that “split CFDP entity”.  
 
See if this diagram clarifies it (correctly).  I may still not be understanding what you have really 
done.
 
Best regards, Peter
 
 
From: Holger Dreihahn <Holger.Dreihahn at esa.int> 
Date: Tuesday, March 14, 2023 at 12:42 AM 
To: Peter Shames <peter.m.shames at jpl.nasa.gov> 
Cc: Felix Flentge <Felix.Flentge at esa.int> 
Subject: [EXTERNAL] FW: CESG-P-2023-02-002 Approval to publish CCSDS 922.27-O-1, 
Cross Support Transfer Service—Return CFDP PDU Service (Orange Book, Issue 1)
 
Dear Peter,
First of all thanks for the thorough review, I think this will make the book better. However, 
before embarking on the changes I want to seek an agreement with you. I think your 
fundamental point is that there is a modified CFDP entity involved, which is very true. I wanted 
to get your opinion, if you would agree with the following argumentation before changing the 
book along those lines: the two grey boxes shown below, CFDP Protocol entity (modified to 
cope with reduced CFDP PDUs) and CFDP File Reconstruction form from a logical point of view a 
CFDP entity as per CFDP book. In fact from a spacecraft point of view, this is exactly the case. 
The RCFDP service now allows you to realize a terrestrial distribution of that CFDP entity, to 
cope with the constraints we have (one file transfer over several ESLTs, terrestrial data transfer 
rate much slower than space link).
 
To my understanding the RCFDP in the ESLT (or elsewhere) does not really process or realize the 
CFDP protocol; it only serves the purpose of transfer, buffering and reducing CFDP PDUs. The 
reducing requires knowledge about the structure of a CFDP PDU, but not more. As such I would 
not see the distribution of CFDP over the EUN(s) and the ESLT.
 
Let me know if that would work for you.
 
Best regards,
Holger 
 
 
 
 
On 10.03.23, 23:04, "CCSDS Secretariat" <thomas.gannett at tgannett.net 
<mailto:thomas.gannett at tgannett.net>> wrote:
 
 
Dear Document Rapporteur,
 
 
The CESG poll to approve publication of CCSDS 922.27-O-1, Cross Support Transfer Service—
Return CFDP PDU Service (Orange Book, Issue 1) concluded with conditions. Please negotiate 
disposition of the conditions directly with the AD(s) who voted to approve with conditions and 
CC the Secretariat on all related correspondence.
 
 
 
 
CESG E-Poll Identifier: CESG-P-2023-02-002 Approval to publish CCSDS 922.27-O-1, Cross 
Support Transfer Service—Return CFDP PDU Service (Orange Book, Issue 1)
 
 
Results of CESG poll beginning 23 February 2023 and ending 9 March 2023:
 
 
Abstain: 0 (0%) 
Approve Unconditionally: 3 (60%) (Barkley, Merri, Aguilar Sanchez)
Approve with Conditions: 2 (40%) (Shames, Cola)
Disapprove with Comment: 0 (0%) 
 
 
CONDITIONS/COMMENTS:
 
 
Mario Merri (Approve Unconditionally): This is not a condition, but rather a question. Orange 
books are typically single agency experimental specifications. Shoudn't this single agency be 
named at the beginning of the document? I see that there is reference to ESA in an annex.
 
 
Peter Shames (Approve with Conditions): After reading this document, and considering all that is 
addressed, I believe that there are actually two separate, but related protocol entities defined:
 
 
1) The experimental RFCDP-CSTS that provides a transfer (and buffering) service for standard, or 
“reduced” CFDP PDUs, and
 
 
2) A modified CFDP protocol entity that is effectively split between the ESLT and the EUN, and 
that can create and process both standard and “reduced” CFDP PDUs.
 
 
The text and the diagrams are not really clear about both of these two different protocol 
entities and how they are intended to operate together. See attached text, with mark-ups, for 
requested fixes.
 
 
Tomaso de Cola (Approve with Conditions): The reading of sections 1-2 is not so easy since a 
high-level description of the document scope is given, which does not allow to get the full 
picture in my opinion. In particular, the diagrams from Section 2 should be more elaborate to 
show how the proposed service fit with respect to the original CFDP implementation through 
the different network elements so involved. The current diagrams are in my opinion too high-
level so that it's not clear how it should work in fact.
 
 
For the sake of the readability, I'd add a few explanatory paragraphs in the normative annexes 
where ASN.1 specifications are given. As it is now, at first glance it is not clear what those ASN.1 
specifications are about.
 
 
 
 
Total Respondents: 5
 
 
All Areas responded to this question.
 
 
 
 
 
 
SECRETARIAT INTERPRETATION OF RESULTS: Approved with Conditions
PROPOSED SECRETARIAT ACTION: Generate CMC poll after conditions have been addressed
 
 
* * * * * * * * * * * * * * * * * * * * * * * *
 
 
 
 
 
 
This message is intended only for the recipient(s) named above. It may contain proprietary 
information and/or protected content. Any unauthorised disclosure, use, retention or 
dissemination is prohibited. If you have received this e-mail in error, please notify the sender 
immediately. ESA applies appropriate organisational measures to protect personal data, in case 
of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int). 
This message is intended only for the recipient(s) named above. It may contain proprietary 
information and/or protected content. Any unauthorised disclosure, use, retention or 
dissemination is prohibited. If you have received this e-mail in error, please notify the sender 
immediately. ESA applies appropriate organisational measures to protect personal data, in case 
of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int). 
This message is intended only for the recipient(s) named above. It may contain proprietary information 
and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If 
you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate 
organisational measures to protect personal data, in case of data privacy queries, please contact the ESA 
Data Protection Officer (dpo at esa.int). 
This message is intended only for the recipient(s) named above. It may contain proprietary information 
and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If 
you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate 
organisational measures to protect personal data, in case of data privacy queries, please contact the ESA 
Data Protection Officer (dpo at esa.int). 
This message is intended only for the recipient(s) named above. It may contain proprietary information 
and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If 
you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate 
organisational measures to protect personal data, in case of data privacy queries, please contact the ESA 
Data Protection Officer (dpo at esa.int). 
This message is intended only for the recipient(s) named above. It may contain proprietary 
information and/or protected content. Any unauthorised disclosure, use, retention or 
dissemination is prohibited. If you have received this e-mail in error, please notify the sender 
immediately. ESA applies appropriate organisational measures to protect personal data, in case 
of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).