<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mv="http://macVmlSchemaUri" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Title" content="">
<meta name="Keywords" content="">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:Arial;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:"Courier New";
        panose-1:2 7 3 9 2 2 5 2 4 4;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Courier;}
span.EmailStyle19
        {mso-style-type:personal;
        font-family:Calibri;
        color:windowtext;}
span.EmailStyle20
        {mso-style-type:personal;
        font-family:Calibri;
        color:windowtext;}
span.EmailStyle21
        {mso-style-type:personal;
        font-family:Calibri;
        color:windowtext;}
span.EmailStyle22
        {mso-style-type:personal-reply;
        font-family:Calibri;
        color:windowtext;}
span.msoIns
        {mso-style-type:export-only;
        mso-style-name:"";
        text-decoration:underline;
        color:teal;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style>
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Unlike a lot of Internet apps that dynamically create and consume data, on the fly, most mission ops is a very deliberative process.  Plans are made and checked.  Commands are made and
 checked.  Behavior of commands may be simulated.  Data (with the commands) is prepared and queued up so that when the scheduled comm network time slot occurs it is ready.  Antennas are pointed "ahead" at where the spacecraft will be, tens of minutes or hours
 (depending upon light time) after the time of radiation.  The spacecraft may need to stop observations at the appointed time, slew to "Earth point" and prepare to receive data, tens of minutes or hours after it was radiated.  The data is received by the spacecraft,
 validated and stored.  At some future time, when the relay link is available (essentially that same transmit receive sequence, but usually a shorter RTLT), the LH service uses the meta-data in the file (or blob) to drive the delivery process.  DTN is involved
 in the end to end (user to relay S/C) delivery, but so is all this other stuff.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Most of the time, in between these steps, there is some sort of file storage system used.  In fact, I would bet that a lot of missions who will use this service would keep a standard "re-boot
 sequence" file handy, and upload it to whichever relay is in view when it is needed.  The obvious thing, at least to my old fashioned mind, is to do this all using files, file storage, file names, file management.  I am sure that we could use object databases,
 or concoct "blob" or "bundle" databases, but do we gain anything by that?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">I do not want to stand in the way of progress, but I do think we need to be realistic about physics (and typical S/C operations).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Peter<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in">
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-family:Calibri;color:black">From: </span>
</b><span style="font-family:Calibri;color:black">Keith Scott <kscott@mitre.org><br>
<b>Date: </b>Tuesday, September 27, 2016 at 1:53 PM<br>
<b>To: </b>Peter Shames <peter.m.shames@jpl.nasa.gov>, Gian Paolo Calzolari <Gian.Paolo.Calzolari@esa.int>, "Tomaso.deCola@dlr.de" <Tomaso.deCola@dlr.de><br>
<b>Cc: </b>CCSDS Engineering Steering Group - CESG Exec <cesg@mailman.ccsds.org><br>
<b>Subject: </b>Re: CFDP as encapsulator : [CESG] IOAG: Service Catalogue #1 / File Services warning (complete)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">I don’t think so – the stuff that’s being sent is meant to be consumed by an application at the receiver – an application that knows how all the goop was put together at the source.  So
 the source collects a bunch of data, metadata, instructions, etc., cobbles it all together according to the to-be-defined spec, serializes the lot and ships it.  The receiver receives it, breaks it all apart, and does whatever it needs to with the data.  Saves
 the step of making a ‘dummy’ file with all the goop.  If the receiver wants to write the received bundle, or broken-out goop, or whatever, to a file, have at it.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">I think all it requires is the definition of a bundle service identifier (e.g. the number ‘16’) for this service (say, last-hop-commanding).  [and all the data processing specification
 that’s independent of bundles or files or whatever.]</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">                --keith</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-family:Calibri;color:black">From: </span>
</b><span style="font-family:Calibri;color:black">Peter Shames <peter.m.shames@jpl.nasa.gov><br>
<b>Date: </b>Tuesday, September 27, 2016 at 4:48 PM<br>
<b>To: </b>Keith Scott <kscott@mitre.org>, Gian Calzolari <Gian.Paolo.Calzolari@esa.int>, "Tomaso.deCola@dlr.de" <Tomaso.deCola@dlr.de><br>
<b>Cc: </b>CCSDS Exec <cesg@mailman.ccsds.org><br>
<b>Subject: </b>Re: CFDP as encapsulator : [CESG] IOAG: Service Catalogue #1 / File Services warning (complete)</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Does that mean that we need to also define "bundle names", and "bundle types" and "bundle management" and "bundle stores" instead of the file system equivalents that already exist?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">-p</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-family:Calibri;color:black">From: </span>
</b><span style="font-family:Calibri;color:black">Keith Scott <kscott@mitre.org><br>
<b>Date: </b>Tuesday, September 27, 2016 at 1:43 PM<br>
<b>To: </b>Gian Paolo Calzolari <Gian.Paolo.Calzolari@esa.int>, "Tomaso.deCola@dlr.de" <Tomaso.deCola@dlr.de><br>
<b>Cc: </b>CCSDS Engineering Steering Group - CESG Exec <cesg@mailman.ccsds.org>, "cesg-bounces@mailman.ccsds.org" <cesg-bounces@mailman.ccsds.org>, Peter Shames <peter.m.shames@jpl.nasa.gov><br>
<b>Subject: </b>Re: CFDP as encapsulator : [CESG] IOAG: Service Catalogue #1 / File Services warning (complete)</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">OK, but if I define how that data is collected into a blob, can’t I ship that blob as a bundle instead of a file?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">                                --keith</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-family:Calibri;color:black">From: </span>
</b><span style="font-family:Calibri;color:black">Gian Calzolari <Gian.Paolo.Calzolari@esa.int><br>
<b>Date: </b>Tuesday, September 27, 2016 at 2:28 PM<br>
<b>To: </b>"Tomaso.deCola@dlr.de" <Tomaso.deCola@dlr.de><br>
<b>Cc: </b>CCSDS Exec <cesg@mailman.ccsds.org>, "cesg-bounces@mailman.ccsds.org" <cesg-bounces@mailman.ccsds.org>, Keith Scott <kscott@mitre.org>, Peter Shames <peter.m.shames@jpl.nasa.gov><br>
<b>Subject: </b>CFDP as encapsulator : [CESG] IOAG: Service Catalogue #1 / File Services warning (complete)</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:Helvetica">Tomaso,
</span><br>
<span style="font-size:10.0pt;font-family:Helvetica">        I think the reason of using CFDP was to move a collection of data. So the encapsulator was rather the file than CFDP.</span>
<br>
<span style="font-size:10.0pt;font-family:Helvetica">Ciao</span> <br>
<br>
<span style="font-size:10.0pt;font-family:Helvetica">Gian Paolo</span> <br>
<br>
<br>
<br>
<span style="font-size:7.5pt;font-family:Helvetica;color:#5F5F5F">From:        </span><span style="font-size:7.5pt;font-family:Helvetica"><Tomaso.deCola@dlr.de></span>
<br>
<span style="font-size:7.5pt;font-family:Helvetica;color:#5F5F5F">To:        </span><span style="font-size:7.5pt;font-family:Helvetica"><kscott@mitre.org></span>
<br>
<span style="font-size:7.5pt;font-family:Helvetica;color:#5F5F5F">Cc:        </span><span style="font-size:7.5pt;font-family:Helvetica"><peter.m.shames@jpl.nasa.gov>, <Gian.Paolo.Calzolari@esa.int>, <cesg-bounces@mailman.ccsds.org>, <cesg@mailman.ccsds.org></span>
<br>
<span style="font-size:7.5pt;font-family:Helvetica;color:#5F5F5F">Date:        </span><span style="font-size:7.5pt;font-family:Helvetica">27/09/2016 20:13</span>
<br>
<span style="font-size:7.5pt;font-family:Helvetica;color:#5F5F5F">Subject:        </span><span style="font-size:7.5pt;font-family:Helvetica">Re: [CESG] IOAG: Service Catalogue #1 / File Services warning (complete)</span>
<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" noshade="" style="color:#AAAAAA" align="center">
</div>
<p class="MsoNormal"><br>
<br>
<br>
I also see the use of CFDP as encapsulator not so efficient. Probably at the time it was conceived with 4 classes, core and extended procedures, it could have made more sense. But now looking at future missions we might want to consider something lighter and
 at the same time more efficient, at least in my view. <br>
<br>
Tomaso<br>
<br>
Sent from my iPhone <br>
<br>
On 27 Sep 2016, at 19:52, Scott, Keith L. <<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>> wrote:<br>
<br>
<span style="font-size:10.0pt;font-family:Calibri">Peter,</span> <br>
<span style="font-size:10.0pt;font-family:Calibri"> </span> <br>
<span style="font-size:10.0pt;font-family:Calibri">OK, maybe my notion of co-opting the FF service over BP to implement fh/lh was/is premature or insane.</span>
<br>
<span style="font-size:10.0pt;font-family:Calibri"> </span> <br>
<span style="font-size:10.0pt;font-family:Calibri">Gipo:  While service catalog 2 may mention CFDP as an implementation mechanism for the FH/LH service I think that’s the wrong way to go.  Since service catalog 2 is in the future (as you point out) we (should)
 have the flexibility to change our minds about how the implementation should work and not be tied to something that got put there as a placeholder some number of years ago.  This argument is of course predicated on my ability to convince you and others that
 a fh/lh app over BP is “better than” (by some metric(s)) fh/lh over cfdp over bp.</span>
<br>
<span style="font-size:10.0pt;font-family:Calibri"> </span> <br>
<span style="font-size:10.0pt;font-family:Calibri">                                --keith</span>
<br>
<span style="font-size:10.0pt;font-family:Calibri"> </span> <br>
<b><span style="font-family:Calibri">From: </span></b><span style="font-family:Calibri">Peter Shames <</span><a href="mailto:peter.m.shames@jpl.nasa.gov"><span style="font-family:Calibri">peter.m.shames@jpl.nasa.gov</span></a><span style="font-family:Calibri">><b><br>
Date: </b>Tuesday, September 27, 2016 at 1:27 PM<b><br>
To: </b>Keith Scott <</span><a href="mailto:kscott@mitre.org"><span style="font-family:Calibri">kscott@mitre.org</span></a><span style="font-family:Calibri">>, "</span><a href="mailto:Tomaso.deCola@dlr.de"><span style="font-family:Calibri">Tomaso.deCola@dlr.de</span></a><span style="font-family:Calibri">"
 <</span><a href="mailto:Tomaso.deCola@dlr.de"><span style="font-family:Calibri">Tomaso.deCola@dlr.de</span></a><span style="font-family:Calibri">>, Gian Calzolari <</span><a href="mailto:Gian.Paolo.Calzolari@esa.int"><span style="font-family:Calibri">Gian.Paolo.Calzolari@esa.int</span></a><span style="font-family:Calibri">><b><br>
Cc: </b>"</span><a href="mailto:cesg-bounces@mailman.ccsds.org"><span style="font-family:Calibri">cesg-bounces@mailman.ccsds.org</span></a><span style="font-family:Calibri">" <</span><a href="mailto:cesg-bounces@mailman.ccsds.org"><span style="font-family:Calibri">cesg-bounces@mailman.ccsds.org</span></a><span style="font-family:Calibri">>,
 CCSDS Exec <</span><a href="mailto:cesg@mailman.ccsds.org"><span style="font-family:Calibri">cesg@mailman.ccsds.org</span></a><span style="font-family:Calibri">><b><br>
Subject: </b>Re: [CESG] IOAG: Service Catalogue #1 / File Services warning (complete)</span>
<br>
  <br>
<span style="font-size:10.0pt;font-family:Calibri">Hi Keith,</span> <br>
<span style="font-size:10.0pt;font-family:Calibri"> </span> <br>
<span style="font-size:10.0pt;font-family:Calibri">I agree completely with your first paragraph.  That is a very good description of the first hop / last hop service and the motivation for it.  That service concept also came out of the IOAG SISG work and is
 now in the SCCS ADD.  It is, as agreed, marked as a [Future] service, one that I think you are now starting to define.  I'll also point out that the stack of protocol PDUs that would appear "on the wire" over a space link, would look like this:</span>
<br>
<span style="font-size:10.0pt;font-family:Calibri"> </span> <br>
<span style="font-family:Calibri">-          </span><span style="font-size:10.0pt;font-family:Calibri">FH/LH PDU</span>
<br>
<span style="font-family:"Courier New"">o   </span><span style="font-size:10.0pt;font-family:Calibri">Meta data</span>
<br>
<span style="font-family:"Courier New"">o   </span><span style="font-size:10.0pt;font-family:Calibri">CCSDS frames (destined for the end node)</span>
<br>
<span style="font-family:Calibri">-          </span><span style="font-size:10.0pt;font-family:Calibri">Bundles (BP)</span>
<br>
<span style="font-family:Calibri">-          </span><span style="font-size:10.0pt;font-family:Calibri">LTP (probably)</span>
<br>
<span style="font-family:Calibri">-          </span><span style="font-size:10.0pt;font-family:Calibri">CCSDS space data link frames (for the relay node)</span>
<br>
<span style="font-family:Calibri">-          </span><span style="font-size:10.0pt;font-family:Calibri">And the usual space link coding, modulation, etc</span>
<br>
<span style="font-size:10.0pt;font-family:Calibri"> </span> <br>
<span style="font-size:10.0pt;font-family:Calibri">So that is a case of "CCSDS Link over BP", but it is only for the express purpose of kick-starting an end node that was in trouble, or for communicating with an end node that was never BP enabled.</span>
<br>
<span style="font-size:10.0pt;font-family:Calibri"> </span> <br>
<span style="font-size:10.0pt;font-family:Calibri">In your second paragraph the first sentence sounds fine, but in the last two sentences things sort of, from my point of view, go off the rails. The F-Frame, as defined, is really quite different from the LH/FH
 service.  I think that the SCCS-ADD makes those differences quite clear so I won't try and re-describe them here.  In the current deployed Internet, as used under SLE and CSTS, the protocols that are used terrestrially are TCP/IP and that is what SLE and CSTS
 are predicated on.  There's even a spec that describes what that stack looks like and it says nothing about running SLE/CSTS over BP.  I will grant you, however, that in some future we could be running DTN everywhere, terrestrially and in space, and in that
 future CSTS could be run over BP instead of TCP/IP.  </span> <br>
<span style="font-size:10.0pt;font-family:Calibri"> </span> <br>
<span style="font-size:10.0pt;font-family:Calibri">That said, even in that future state, it would still have to be the case that the transport of BP bundles, over the space link, would be done over the usual sort of space link protocol (USLP would be my choice)
 and over some sort of suitable coding and modulation, with some sort of suitable ranging signals.  These could be RF or optical, where "suitable" depends on distances, data rates, require coding gain, etc.   I do not think it would ever be accurate to say
 that we would carry "space link over BP" in that future except in the FH/LH circumstance, or something like it.</span>
<br>
<span style="font-size:10.0pt;font-family:Calibri"> </span> <br>
<span style="font-size:10.0pt;font-family:Calibri">Regards, Peter</span> <br>
<span style="font-size:10.0pt;font-family:Calibri"> </span> <br>
<span style="font-size:10.0pt;font-family:Calibri"> </span> <br>
<b><span style="font-family:Calibri">From: </span></b><span style="font-family:Calibri">Keith Scott <</span><a href="mailto:kscott@mitre.org"><span style="font-family:Calibri">kscott@mitre.org</span></a><span style="font-family:Calibri">><b><br>
Date: </b>Tuesday, September 27, 2016 at 10:08 AM<b><br>
To: </b>"</span><a href="mailto:Tomaso.deCola@dlr.de"><span style="font-family:Calibri">Tomaso.deCola@dlr.de</span></a><span style="font-family:Calibri">" <</span><a href="mailto:Tomaso.deCola@dlr.de"><span style="font-family:Calibri">Tomaso.deCola@dlr.de</span></a><span style="font-family:Calibri">>,
 Peter Shames <</span><a href="mailto:peter.m.shames@jpl.nasa.gov"><span style="font-family:Calibri">peter.m.shames@jpl.nasa.gov</span></a><span style="font-family:Calibri">>, Gian Paolo Calzolari <</span><a href="mailto:Gian.Paolo.Calzolari@esa.int"><span style="font-family:Calibri">Gian.Paolo.Calzolari@esa.int</span></a><span style="font-family:Calibri">><b><br>
Cc: </b>"</span><a href="mailto:cesg-bounces@mailman.ccsds.org"><span style="font-family:Calibri">cesg-bounces@mailman.ccsds.org</span></a><span style="font-family:Calibri">" <</span><a href="mailto:cesg-bounces@mailman.ccsds.org"><span style="font-family:Calibri">cesg-bounces@mailman.ccsds.org</span></a><span style="font-family:Calibri">>,
 CCSDS Engineering Steering Group - CESG Exec <</span><a href="mailto:cesg@mailman.ccsds.org"><span style="font-family:Calibri">cesg@mailman.ccsds.org</span></a><span style="font-family:Calibri">><b><br>
Subject: </b>Re: [CESG] IOAG: Service Catalogue #1 / File Services warning (complete)</span>
<br>
  <br>
<span style="font-size:10.0pt;font-family:Calibri">Right, this is the notion in the ICPA of what Chris Taylor referred to as ‘first-hop / last-hop’ services.  If you’ve got a spacecraft that is otherwise SSI-aware but is now in trouble, it might not HAVE DTE
 capability and the only way to get emergency link-layer commands to it (assuming it was built to do that, which seems reasonable) would be to ship a bunch of frames to some SSI-enabled spacecraft NEAR the troubled one, then blast those frames at the troubled
 one.  My notion is that this is a standardized application that could be present on all (ok, many) SSI-enabled spacecraft, and the standardization bit is in how to express the ‘here’s what to send and here’s how to send it’ part.  The content (data + instructions)
 is shipped to the functioning spacecraft over one of the the SSI networking protocols (BP or IP).</span>
<br>
<span style="font-size:10.0pt;font-family:Calibri"> </span> <br>
<span style="font-size:10.0pt;font-family:Calibri">My understanding is that the FF service takes frames, moves them somewhere, combines them with other stuff and/or does whatever needs to be done to form a transmittable serialized stream of bits, and hands
 that stream off for radiation.  If that understanding is correct, if I use bundles as the shipment mechanism, FF service is pretty much a description of the SSI first hop / last hop service.  And, I hope that unless there’s a need to be more specific, the
 forward frame service could use any number of underlying mechanisms for shipment (e.g. TCP/IP suite, BP, etc.)</span>
<br>
<span style="font-size:10.0pt;font-family:Calibri"> </span> <br>
<span style="font-size:10.0pt;font-family:Calibri">                                --keith</span>
<br>
<span style="font-size:10.0pt;font-family:Calibri"> </span> <br>
<b><span style="font-family:Calibri">From: </span></b><span style="font-family:Calibri">"</span><a href="mailto:Tomaso.deCola@dlr.de"><span style="font-family:Calibri">Tomaso.deCola@dlr.de</span></a><span style="font-family:Calibri">" <</span><a href="mailto:Tomaso.deCola@dlr.de"><span style="font-family:Calibri">Tomaso.deCola@dlr.de</span></a><span style="font-family:Calibri">><b><br>
Date: </b>Tuesday, September 27, 2016 at 12:59 PM<b><br>
To: </b>Peter Shames <</span><a href="mailto:peter.m.shames@jpl.nasa.gov"><span style="font-family:Calibri">peter.m.shames@jpl.nasa.gov</span></a><span style="font-family:Calibri">>, Gian Calzolari <</span><a href="mailto:Gian.Paolo.Calzolari@esa.int"><span style="font-family:Calibri">Gian.Paolo.Calzolari@esa.int</span></a><span style="font-family:Calibri">>,
 Keith Scott <</span><a href="mailto:kscott@mitre.org"><span style="font-family:Calibri">kscott@mitre.org</span></a><span style="font-family:Calibri">><b><br>
Cc: </b>"</span><a href="mailto:cesg-bounces@mailman.ccsds.org"><span style="font-family:Calibri">cesg-bounces@mailman.ccsds.org</span></a><span style="font-family:Calibri">" <</span><a href="mailto:cesg-bounces@mailman.ccsds.org"><span style="font-family:Calibri">cesg-bounces@mailman.ccsds.org</span></a><span style="font-family:Calibri">>,
 CCSDS Exec <</span><a href="mailto:cesg@mailman.ccsds.org"><span style="font-family:Calibri">cesg@mailman.ccsds.org</span></a><span style="font-family:Calibri">><b><br>
Subject: </b>RE: [CESG] IOAG: Service Catalogue #1 / File Services warning (complete)</span>
<br>
  <br>
<span style="font-size:10.0pt;font-family:Calibri;color:#004080">If I don’t misinterpret Keith’s statement, I think it is about exploiting tunneling capabilities of the bundle protocol so that is able to transport “blindly” CCSDS frames. Obviously we don’t
 want to flip the CCSDS protocol stack.</span> <br>
<span style="font-size:10.0pt;font-family:Calibri;color:#004080"> </span> <br>
<span style="font-size:10.0pt;font-family:Calibri;color:#004080">Tomaso </span><br>
<span style="font-size:10.0pt;font-family:Calibri;color:#004080"> </span> <br>
<span style="font-size:10.0pt;font-family:Arial;color:#5F5F5F">————————————————————————</span><span style="color:#004080">
</span><b><span style="font-size:10.0pt;font-family:Arial;color:#5F5F5F"><br>
Deutsches Zentrum für Luft- und Raumfahrt</span></b><span style="font-size:10.0pt;font-family:Arial;color:#5F5F5F"> (DLR)</span><span style="color:#004080">
</span><span style="font-size:10.0pt;font-family:Arial;color:#5F5F5F"><br>
German Aerospace Center</span><span style="color:#004080"> </span><span style="font-size:10.0pt;font-family:Arial;color:#5F5F5F"><br>
Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany</span><span style="color:#004080">
</span><br>
<b><span style="font-size:10.0pt;font-family:Arial;color:#5F5F5F">Tomaso de Cola, Ph.D.</span></b><span style="font-size:10.0pt;font-family:Calibri;color:#004080">
</span><span style="font-size:10.0pt;font-family:Arial;color:#5F5F5F"><br>
Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 |</span><span style="font-size:10.0pt;font-family:Arial;color:#004080">
</span><a href="mailto:tomaso.decola@dlr.de"><span style="font-size:10.0pt;font-family:Arial">tomaso.decola@dlr.de</span></a><span style="font-size:10.0pt;font-family:Calibri;color:#004080">
</span><u><span style="font-size:10.0pt;font-family:Arial;color:blue"><br>
</span></u><a href="http://www.dlr.de/kn/institut/abteilungen/san"><span style="font-size:10.0pt;font-family:Arial">http://www.dlr.de/kn/institut/abteilungen/san</span></a><span style="font-size:10.0pt;font-family:Calibri;color:#004080">
</span><br>
<span style="font-size:10.0pt;font-family:Calibri;color:#004080"> </span> <br>
<b><span style="font-size:10.0pt;font-family:Tahoma">From:</span></b><span style="font-size:10.0pt;font-family:Tahoma"> CESG [</span><a href="mailto:cesg-bounces@mailman.ccsds.org"><span style="font-size:10.0pt;font-family:Tahoma">mailto:cesg-bounces@mailman.ccsds.org</span></a><span style="font-size:10.0pt;font-family:Tahoma">]
<b>On Behalf Of </b>Shames, Peter M (312B)<b><br>
Sent:</b> Tuesday, September 27, 2016 6:35 PM<b><br>
To:</b> </span><a href="mailto:Gian.Paolo.Calzolari@esa.int"><span style="font-size:10.0pt;font-family:Tahoma">Gian.Paolo.Calzolari@esa.int</span></a><span style="font-size:10.0pt;font-family:Tahoma">; Scott, Keith L.<b><br>
Cc:</b> CESG; CCSDS Engineering Steering Group - CESG Exec(</span><a href="mailto:cesg@mailman.ccsds.org"><span style="font-size:10.0pt;font-family:Tahoma">cesg@mailman.ccsds.org</span></a><span style="font-size:10.0pt;font-family:Tahoma">)<b><br>
Subject:</b> Re: [CESG] IOAG: Service Catalogue #1 / File Services warning (complete)</span>
<br>
  <br>
<span style="font-size:10.0pt;font-family:Calibri">Gotta say I agree with Gippo on the last part of this.  I too found that
</span><span style="font-size:10.0pt;font-family:Arial">"</span><span style="font-size:10.0pt;font-family:Calibri">forward frame service running over bundles</span><span style="font-size:10.0pt;font-family:Arial">" statement
</span><span style="font-size:10.0pt;font-family:Calibri">very confusing.  Was it a typo?</span>
<br>
<span style="font-size:10.0pt;font-family:Calibri"> </span> <br>
<span style="font-size:10.0pt;font-family:Calibri">The operating assumption, as documented in SCCS-ADD, is that DTN bundles run on top of CCSDS frames and thus on top of CSTS services, not underneath them.</span>
<br>
<span style="font-size:10.0pt;font-family:Calibri"> </span> <br>
<span style="font-size:10.0pt;font-family:Calibri">Peter</span> <br>
<span style="font-size:10.0pt;font-family:Calibri"> </span> <br>
<span style="font-size:10.0pt;font-family:Calibri"> </span> <br>
<b><span style="font-family:Calibri">From: </span></b><span style="font-family:Calibri">Gian Paolo Calzolari <</span><a href="mailto:Gian.Paolo.Calzolari@esa.int"><span style="font-family:Calibri">Gian.Paolo.Calzolari@esa.int</span></a><span style="font-family:Calibri">><b><br>
Date: </b>Tuesday, September 27, 2016 at 8:32 AM<b><br>
To: </b>Keith Scott <</span><a href="mailto:kscott@mitre.org"><span style="font-family:Calibri">kscott@mitre.org</span></a><span style="font-family:Calibri">><b><br>
Cc: </b>CCSDS Engineering Steering Group - CESG Exec <</span><a href="mailto:cesg@mailman.ccsds.org"><span style="font-family:Calibri">cesg@mailman.ccsds.org</span></a><span style="font-family:Calibri">>, CESG <</span><a href="mailto:cesg-bounces@mailman.ccsds.org"><span style="font-family:Calibri">cesg-bounces@mailman.ccsds.org</span></a><span style="font-family:Calibri">>,
 Nestor Peccia <</span><a href="mailto:Nestor.Peccia@esa.int"><span style="font-family:Calibri">Nestor.Peccia@esa.int</span></a><span style="font-family:Calibri">>, Peter Shames <</span><a href="mailto:peter.m.shames@jpl.nasa.gov"><span style="font-family:Calibri">peter.m.shames@jpl.nasa.gov</span></a><span style="font-family:Calibri">><b><br>
Subject: </b>Re: [CESG] IOAG: Service Catalogue #1 / File Services warning (complete)</span>
<br>
  <br>
<span style="font-size:10.0pt;font-family:Arial">Keith, <br>
      try to keep in mind that an IOAG Service is indeed a collection of Space Link Interface Standards & Ground Link Interface Standards.
<br>
Moreover, as Nestor underlined, Catalog 1 is for ABA configuration and the CFDP transmission only covers the single hop space to ground (or vice versa).</span>
<br>
<span style="font-size:10.0pt;font-family:Arial"><br>
When you say "</span><span style="font-size:10.0pt;font-family:Calibri">  I understood the forward file service to have evolved into a mechanism/semantic for zipping a bunch of stuff together (metadata, data, etc.)
</span><span style="font-size:10.0pt;font-family:Arial">" I think you refer to the  Ground Link Interface Standard under development in CSS; i.e. only to a part of the IOAG Serrvice.</span>
<span style="color:red"><br>
</span><span style="font-size:10.0pt;font-family:Arial;color:red"><br>
Last but not least I am very puzzled by the statement "</span><span style="font-size:10.0pt;font-family:Calibri;color:red">forward frame service running over bundles</span><span style="font-size:10.0pt;font-family:Arial;color:red">". Catalog 2 states that <<The
 CSTS Forward Frame Services above is “to be written”. It is assumed that this Service will provide a forward frame service for [AOS] and [TC-DLP] implementing multiplexing, frame fill and coding in the provider and implementing the full stack down to the physical
 layer>> so having AOS or TC frames running over bundles would reverse our CSCDS Stack where are bundles that - throug e.g. encapsulation service - run over AOS and TC frames.</span><span style="color:red">
</span><br>
<span style="font-size:10.0pt;font-family:Arial"><br>
Regards</span> <br>
<span style="font-size:10.0pt;font-family:Arial"><br>
Gian Paolo</span> <br>
<br>
<br>
<span style="font-size:7.5pt;font-family:Arial;color:#5F5F5F"><br>
From:        </span><span style="font-size:7.5pt;font-family:Arial">"Scott, Keith L." <</span><a href="mailto:kscott@mitre.org"><span style="font-size:7.5pt;font-family:Arial">kscott@mitre.org</span></a><span style="font-size:7.5pt;font-family:Arial">></span>
<span style="font-size:7.5pt;font-family:Arial;color:#5F5F5F"><br>
To:        </span><span style="font-size:7.5pt;font-family:Arial">"Shames, Peter M (312B)" <</span><a href="mailto:peter.m.shames@jpl.nasa.gov"><span style="font-size:7.5pt;font-family:Arial">peter.m.shames@jpl.nasa.gov</span></a><span style="font-size:7.5pt;font-family:Arial">>,
 "</span><a href="mailto:Nestor.Peccia@esa.int"><span style="font-size:7.5pt;font-family:Arial">Nestor.Peccia@esa.int</span></a><span style="font-size:7.5pt;font-family:Arial">" <</span><a href="mailto:Nestor.Peccia@esa.int"><span style="font-size:7.5pt;font-family:Arial">Nestor.Peccia@esa.int</span></a><span style="font-size:7.5pt;font-family:Arial">>,
 "CCSDS Engineering Steering Group - CESG Exec(</span><a href="mailto:cesg@mailman.ccsds.org"><span style="font-size:7.5pt;font-family:Arial">cesg@mailman.ccsds.org</span></a><span style="font-size:7.5pt;font-family:Arial">)" <</span><a href="mailto:cesg@mailman.ccsds.org"><span style="font-size:7.5pt;font-family:Arial">cesg@mailman.ccsds.org</span></a><span style="font-size:7.5pt;font-family:Arial">></span>
<span style="font-size:7.5pt;font-family:Arial;color:#5F5F5F"><br>
Date:        </span><span style="font-size:7.5pt;font-family:Arial">26/09/2016 22:06</span>
<span style="font-size:7.5pt;font-family:Arial;color:#5F5F5F"><br>
Subject:        </span><span style="font-size:7.5pt;font-family:Arial">Re: [CESG] IOAG: Service Catalogue #1</span>
<span style="font-size:7.5pt;font-family:Arial;color:#5F5F5F"><br>
Sent by:        </span><span style="font-size:7.5pt;font-family:Arial">"CESG" <</span><a href="mailto:cesg-bounces@mailman.ccsds.org"><span style="font-size:7.5pt;font-family:Arial">cesg-bounces@mailman.ccsds.org</span></a><span style="font-size:7.5pt;font-family:Arial">></span>
<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" noshade="" style="color:#AAAAAA" align="center">
</div>
<p class="MsoNormal"><br>
<br>
<br>
<span style="font-size:10.0pt;font-family:Calibri"><br>
Peter,</span> <span style="font-size:10.0pt;font-family:Calibri"><br>
</span> <span style="font-size:10.0pt;font-family:Calibri"><br>
I think I agree with you.  My concern from the beginning has been that I do not want the forward file service to morph into a way to try to do multi-hop forwarding using file transfers as the ‘data link’ mechanism.  I understood the forward file service to
 have evolved into a mechanism/semantic for zipping a bunch of stuff together (metadata, data, etc.) to be used by the end system application (the receiver end of the data transfer), with possibly some application semantics layered on top.</span>
<span style="font-size:10.0pt;font-family:Calibri"><br>
</span> <span style="font-size:10.0pt;font-family:Calibri"><br>
In fact, if the forward-XXX services were generalized just a bit, I think they’d cover the DTN emergency command/telemetry case.  Or maybe the DTN emergency commanding service is the forward frame service running over bundles, I hadn’t thought of that until
 now but I like it.  If part of the CSTS forward-frame service states how to tunnel (in my case, FRAMES) to a remote location and then radiate them, and if it can be run over BP as a transport mechanism…   It would address an IOAG need, at least.</span>
<span style="font-size:10.0pt;font-family:Calibri"><br>
</span> <span style="font-size:10.0pt;font-family:Calibri"><br>
                               --keith</span> <span style="font-size:10.0pt;font-family:Calibri">
<br>
</span> <span style="font-size:10.0pt;font-family:Calibri"><br>
</span> <b><span style="font-family:Calibri"><br>
From: </span></b><span style="font-family:Calibri">"</span><a href="mailto:cesg-bounces@mailman.ccsds.org"><span style="font-family:Calibri">cesg-bounces@mailman.ccsds.org</span></a><span style="font-family:Calibri">" <</span><a href="mailto:cesg-bounces@mailman.ccsds.org"><span style="font-family:Calibri">cesg-bounces@mailman.ccsds.org</span></a><span style="font-family:Calibri">>
 on behalf of Peter Shames <</span><a href="mailto:peter.m.shames@jpl.nasa.gov"><span style="font-family:Calibri">peter.m.shames@jpl.nasa.gov</span></a><span style="font-family:Calibri">><b><br>
Date: </b>Monday, September 26, 2016 at 3:33 PM<b><br>
To: </b>Nestor Peccia <</span><a href="mailto:Nestor.Peccia@esa.int"><span style="font-family:Calibri">Nestor.Peccia@esa.int</span></a><span style="font-family:Calibri">>, CCSDS Exec <</span><a href="mailto:cesg@mailman.ccsds.org"><span style="font-family:Calibri">cesg@mailman.ccsds.org</span></a><span style="font-family:Calibri">><b><br>
Subject: </b>Re: [CESG] IOAG: Service Catalogue #1</span> <br>
 <span style="font-size:10.0pt;font-family:Calibri"><br>
Nestor,</span> <span style="font-size:10.0pt;font-family:Calibri"><br>
</span> <span style="font-size:10.0pt;font-family:Calibri"><br>
I know that this is a late input, but after reading the IOAG Svc Cat #1 I have a very real concern that I think needs to be surfaced.  Four new services have been introduced, the "Forward/Return CFDP-File Service Type" and the "Forward/Return PACKETS-File Service
 Type".  In reading through the descriptions I find that they mention certain SM characteristics, but fail to acknowledge the required presence of a whole lot of "packet / file / frame plumbing" that is missing in most of our current systems.  Of particular
 concern, from a standards and logistics point of view, is that these new standards require a lot of the "plumbing" that CSTS F-Frame is supposed to provide, but make no mention of that standard.  In fact, the precursor standards, "Forward Synchronous Encoded
 Frame Service Type" has been dropped, and what is left is just some sort of weak "forward reference" to a CSTS F-Frame service.</span>
<span style="font-size:10.0pt;font-family:Calibri"><br>
</span> <span style="font-size:10.0pt;font-family:Calibri"><br>
I think this is a huge mistake and that we should push back on it.</span> <span style="font-size:10.0pt;font-family:Calibri">
<br>
</span> <span style="font-size:10.0pt;font-family:Calibri"><br>
Here is the logic behind this:</span> <span style="font-size:10.0pt;font-family:Calibri">
<br>
</span> <br>
1)      <span style="font-size:10.0pt;font-family:Calibri">FF-CSTS includes the key services and functions that are required for anything like forward file, or forward packet, or forward DTN to work.</span>
<br>
2)      <span style="font-size:10.0pt;font-family:Calibri">These functions include, quoting from the report "Users shall be aware that IOAG Service Catalog 2 foresees a future CSTS Forward Frame Service that is assumed will provide a forward service for [AOS]
 and [TC-DLP] frames implementing multiplexing, frame fill and coding in the provider and implementing the full stack down to the physical layer."</span>
<br>
3)      <span style="font-size:10.0pt;font-family:Calibri">In order to implement a forward file or packet service all of these functions,
<b><i>plus</i></b> frame creation, must be present in the service provider.</span>
<br>
4)      <span style="font-size:10.0pt;font-family:Calibri">It makes little technical sense to create forward file and forward packet services, as new separate services that embed all of these function, instead of creating the FF-CSTS service and then building
 CFDP and Packet service "plug-ins" on top of that which use this underlying service.</span>
<span style="font-size:10.0pt;font-family:Calibri"><br>
</span> <span style="font-size:10.0pt;font-family:Calibri"><br>
In fact, this approach is exactly how the forward file service is now described in the SCCS-ADD.  I draw your attention to CCSDS 901.1-M-1, sec 5.2.2.2 and sec 6.2.2.2.  In fact, fig 6-4 shows the relationships among SM, CSTS F-Frame, the associated functions
 that are required, including ranging, and also SLE R-AF, and fig 6-8 (ABA ESLT Forward-File Protocol Building Blocks) shows how F-Frame and Fwd frame are designed to be integrated.  Any sort of forward packet service ought to just be a variant of this.</span>
<span style="font-size:10.0pt;font-family:Calibri"><br>
</span> <span style="font-size:10.0pt;font-family:Calibri"><br>
My recommendation is that CCSDS push back on this IOAG Cat 1 request for two new stand alone services and instead argue that CSTS F-Frame should be done first, and these other new service built upon that base.</span>
<span style="font-size:10.0pt;font-family:Calibri"><br>
</span> <span style="font-size:10.0pt;font-family:Calibri"><br>
Regards, Peter</span> <span style="font-size:10.0pt;font-family:Calibri"><br>
</span> <span style="font-size:10.0pt;font-family:Calibri"><br>
</span> <span style="font-size:10.0pt;font-family:Calibri"><br>
</span> <b><span style="font-family:Calibri"><br>
From: </span></b><span style="font-family:Calibri">CESG <</span><a href="mailto:cesg-bounces@mailman.ccsds.org"><span style="font-family:Calibri">cesg-bounces@mailman.ccsds.org</span></a><span style="font-family:Calibri">> on behalf of Nestor Peccia <</span><a href="mailto:Nestor.Peccia@esa.int"><span style="font-family:Calibri">Nestor.Peccia@esa.int</span></a><span style="font-family:Calibri">><b><br>
Date: </b>Thursday, September 15, 2016 at 3:43 AM<b><br>
To: </b>CCSDS Engineering Steering Group - CESG Exec <</span><a href="mailto:cesg@mailman.ccsds.org"><span style="font-family:Calibri">cesg@mailman.ccsds.org</span></a><span style="font-family:Calibri">><b><br>
Subject: </b>[CESG] IOAG: Service Catalogue #1</span> <br>
 <u><span style="font-size:10.0pt;color:red"><br>
REMINDER</span></u> <span style="font-size:10.0pt"><br>
<br>
Please let me have your comments (in particular from the CSS Area) by 22nd Sept 2016 cob.</span>
<span style="font-size:10.0pt"><br>
<br>
ciao</span> <span style="font-size:10.0pt"><br>
nestor</span> <span style="font-size:10.0pt"><br>
<br>
============================</span> <span style="font-size:10.0pt"><br>
Dear all,</span> <span style="font-size:10.0pt"><br>
<br>
Please  find attached the Service Catalogue #1 that has been approved by the IOAG.
<br>
<br>
You should be aware that the final approval regarding the editorial updates from NASA is still pending. There is an on-going discussion
</span><span style="font-size:10.0pt;font-family:Calibri">concerning service management “function” vs. service management “service”.</span>
<span style="font-size:10.0pt"><br>
<br>
However, this version is good enough to be processed by the CESG.</span> <br>
<span style="font-size:10.0pt"><br>
<br>
[attachment "IOAG Service Catalog One.v2.0-Approved-20160823.pdf" deleted by Nestor Peccia/esoc/ESA]
<br>
[attachment "IOAG Service Catalog One.v2.0-Approved-20160823withBars.pdf" deleted by Nestor Peccia/esoc/ESA]
<br>
<br>
CESG will address this update during our next webex.</span> <span style="font-size:10.0pt">
<br>
<br>
Main changes are :</span> <span style="font-size:10.0pt;font-family:Arial"><br>
1.        </span><span style="font-size:10.0pt">forward / return CFDP file over terrestrial generic file</span>
<span style="font-size:10.0pt;font-family:Arial"><br>
2.        </span><span style="font-size:10.0pt">forward / return packet file service  over terrestrial generic file</span>
<span style="font-size:10.0pt;font-family:Arial"><br>
3.        </span><span style="font-size:10.0pt">Service Management functions</span>
<br>
<span style="font-size:10.0pt"><br>
<br>
ciao</span> <span style="font-size:10.0pt"><br>
nestor</span> <span style="font-size:10.0pt;font-family:"Courier New""><br>
This message and any attachments are intended for the use of the addressee or addressees only.</span>
<span style="font-size:10.0pt;font-family:"Courier New""><br>
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its</span>
<span style="font-size:10.0pt;font-family:"Courier New""><br>
content is not permitted.</span> <span style="font-size:10.0pt;font-family:"Courier New"">
<br>
If you received this message in error, please notify the sender and delete it from your system.</span>
<span style="font-size:10.0pt;font-family:"Courier New""><br>
Emails can be altered and their integrity cannot be guaranteed by the sender.</span>
<span style="font-size:10.0pt;font-family:"Courier New""><br>
</span> <span style="font-size:10.0pt;font-family:"Courier New""><br>
Please consider the environment before printing this email._______________________________________________<br>
CESG mailing list<u><span style="color:blue"><br>
</span></u></span><a href="mailto:CESG@mailman.ccsds.org"><span style="font-size:10.0pt;font-family:"Courier New"">CESG@mailman.ccsds.org</span></a><u><span style="color:blue"><br>
</span></u><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg"><span style="font-size:10.0pt;font-family:"Courier New"">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg</span></a>
<br>
<span style="font-size:10.0pt;font-family:"Courier New"">This message and any attachments are intended for the use of the addressee or addressees only.</span>
<br>
<span style="font-size:10.0pt;font-family:"Courier New"">The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its</span>
<br>
<span style="font-size:10.0pt;font-family:"Courier New"">content is not permitted.</span>
<br>
<span style="font-size:10.0pt;font-family:"Courier New"">If you received this message in error, please notify the sender and delete it from your system.</span>
<br>
<span style="font-size:10.0pt;font-family:"Courier New"">Emails can be altered and their integrity cannot be guaranteed by the sender.</span>
<br>
<span style="font-size:10.0pt;font-family:"Courier New""> </span> <br>
<span style="font-size:10.0pt;font-family:"Courier New"">Please consider the environment before printing this email.</span>
<o:p></o:p></p>
<pre>This message and any attachments are intended for the use of the addressee or addressees only.<o:p></o:p></pre>
<pre>The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its<o:p></o:p></pre>
<pre>content is not permitted.<o:p></o:p></pre>
<pre>If you received this message in error, please notify the sender and delete it from your system.<o:p></o:p></pre>
<pre>Emails can be altered and their integrity cannot be guaranteed by the sender.<o:p></o:p></pre>
<pre> <o:p></o:p></pre>
<pre>Please consider the environment before printing this email.<o:p></o:p></pre>
</blockquote>
</blockquote>
</div>
</body>
</html>