<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="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
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:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1943024579;
mso-list-type:hybrid;
mso-list-template-ids:-11362616 -628164282 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ascii-font-family:Calibri;
mso-fareast-font-family:Calibri;
mso-hansi-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi Erik, Holger,
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">First sorry for not attending last telecons (or badly attending) but I just could not manage that. I’ll try to get better on that, however tomorrow I will not
be able to support the telecon… (so much for my trying, huh?). <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Anyway, for the small discussion below, some of my thoughts:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">For the DLR we are not yet “service” oriented, which means we do not differentiate between a pass and the service which is behind it (or with it, or within,
or whatever). Also as you know we do not have all the great things of service agreements, configuration profiles, etc… Now, what we have in principle is just station allocation and … that’s it. All further details are happening “somehow”. Which does not mean,
we would not like to go for full integration and automation someday, where more precise information (like service type, on/off times, etc… ergo service scheduling) may be required.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">In general I could agree with Holger having more or less two different areas (station allocation and actual service scheduling), whereas I also thought (until
now at least) this was intended by SM to have service scheduling und through that have more or less indirectly station allocation.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">We could say than we have (in narrow terms of service and station requests only) following topics:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Allocation / service planning<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Station allocation/booking in general<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">3.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Service scheduling in detail<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I do not see (directly) any reasons why we may not split point 2 and 3 from each other. This would actually mean, that the agencies like DLR which up to now
use rather rudimentary scheduling, would be probably happy to use just point 2 request type.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">This does not change anything on other uses for our “mother-of-all-requests” (short: MOAR), where we may use it for requesting several different things (like
service agreement, or later on accounting). And it would be nice, if we manage to have common constraints class for all of these types – I think we can do this, because 99% of constraints we will have, cover timings, service types, apertures, spacecraft, etc.
All these things are important (and common!) for planning, allocation, services, accounting, service agreement.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Regarding the question if constraints should be composed or referenced – at the first shot, as we speak of “requests”, I would also agree, that they should
be composed (as being special service, special case related). On the other side I may also imagine the case where specific constraints being already predefined (whatever way) and then just referenced. In such a case however we need the composition possibility
anyway. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Also is pity I can’t participate tomorrow, as Erik promises to go more into details and be less abstract. I hope you’ll make some notes of the meeting, so that
I can follow up.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I hope I was not too chaotic, so my input has some value ;-).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Best Regards<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Marcin<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Barkley, Erik J (3970) [mailto:erik.j.barkley@jpl.nasa.gov]
<br>
<b>Sent:</b> Freitag, 3. Juli 2015 02:40<br>
<b>To:</b> Holger.Dreihahn@esa.int<br>
<b>Cc:</b> Colin.Haddow@esa.int; Chamoun, Jean-Pierre (GSFC-458.0)[Affiliate] (jean-pierre.chamoun@nasa.gov); Gnat, Marcin; CCSDS Service Mgmt WG; Unal, Martin P (9020-Affiliate)<br>
<b>Subject:</b> RE: Abstract service request telecon notes<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Holger,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I recognize more or less the process you have described and there are definite similarities to what I am most familiar with in terms of business process model,
lifecycle, for delivery of TT+C services for the DSN. But there may be other organizations that don’t quite do things the same way or perhaps are using a request in sense that does not have the all of the supporting details (such as service agreement, configuration
profile, event sequence) etc. in place. For example, assuming we are wildly successful (why not?) it may be that someday we have a normative recommendation includes a request for creation of a service agreement. It may be that there are constraints expressed
for each service on an independent basis or at least in some relatively de-coupled manner. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Part of what we are attempting to do here is understand what are the components needed for a service request in the abstract and so this is probably best viewed
as an M-2 model. The idea is to understand what and where are the functional points of articulations for requests in general. Its kind of functional resources for service request. At the M-2 level I tend to be satisfied that there is, in the abstract,
a constraints function. This then is an essential extensibility point that can be subject to restrictions such as you indicated below (ie, constraints only on the entire package of services).
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I think we will know more at our next discussion on this when we see the planning request vs (a more exact DDOR flavored) service package request being compared
and contrasted. In both cases there will likely be some sort of constraints, some sort of service configuration function, some sort of ability to reference other information, etc – these are the items of primary interest at the moment.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-Erik<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">
<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">
<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a> [<a href="mailto:Holger.Dreihahn@esa.int">mailto:Holger.Dreihahn@esa.int</a>]
<br>
<b>Sent:</b> Wednesday, July 01, 2015 2:43 AM<br>
<b>To:</b> Barkley, Erik J (3970)<br>
<b>Cc:</b> <a href="mailto:Colin.Haddow@esa.int">Colin.Haddow@esa.int</a>; Chamoun, Jean-Pierre (GSFC-458.0)[Affiliate] (<a href="mailto:jean-pierre.chamoun@nasa.gov">jean-pierre.chamoun@nasa.gov</a>);
<a href="mailto:Marcin.Gnat@dlr.de">Marcin.Gnat@dlr.de</a>; CCSDS Service Mgmt WG; Unal, Martin P (9020-Affiliate)<br>
<b>Subject:</b> Re: Abstract service request telecon notes<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Hi Erik,</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Thanks for the opportunity to join the discussion. Having a second thought about the request and the discussed option to attach constraints to the provided services I was considering the following:</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">- for the request itself constraints make sense to express flexibility, something like 'I need a an 8-10h pass starting earliest at 12h, latest start at 14h.</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">- for the services within the pass I am not that convinced (anymore):</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif""> \ not all required details might be known at request time</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif""> \ according to my experience missions want to prescribe an exact timing when services (uplink, ranging, doppler measurement etc.) are provided within a pass</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">In our network we now at pass request time the set of required services, the station capability in terms of service provisioning and perform the booking (station allocation plan). However, at that
point in time some details for the service provisioning within the pass are not known. Typically at a later stage missions provide (often by providing mission specific events) the details, which allows the production of executable station schedule, which actually
refines the station allocation plan into a more detailed schedule which logically contains the service provision times (and parameterisation) of the provided services within a pass. In addition to that there may be the need to update the pass allocation timing
at a later stage based on updated orbital predictions.</span> <br>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">I would expect that scenario to be typical for network: Resources (station and others) are booked quite in advance. At this time often not all information (e.g. orbital predictions) is available
at the finally required precision to actually schedule station services correctly. If that is true, shouldn't we reflect that in the abstract service request, i.e. simplify it to what's needed. In our network the equivalent of the service agreement captures
the rules when services are provided within a pass, often this is done by referring mission specific events. Now I do not know exactly, but I would expect the sequence of events to provide a similar sort of functionality.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">As such it looks to me we are mixing up two problems: Station (resources) allocation and service scheduling within the allocated passes. Is that necessarily a good idea? I think this is a fundamental
point we need to discuss. According to a discussion with Martin the resource allocation request need the outlined flexibility to facilitate better resource exploitation. Services within a pass have to be provided according to precise timings with agreed and
validated (parameterised) setup.</span> <br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">The resource allocation is typically an input to mission planning, which results later in the details required to provide the service within the allocated resource booking.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">For the constraints of the request itself I would rate composition (black diamond) as the right way of doing it. For service specific constraints (or details, rules or what it will be) I tend to
agree that those should be references to, ja, do not know exactly but some (static) configuration like the rules captured by the service agreement.
</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Kind regards,</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Holger</span> <br>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | S-431<br>
+49 6151 90 2233 | </span><a href="http://www.esa.int/esoc"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">http://www.esa.int/esoc</span></a>
<br>
<br>
<br>
<br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">From: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif"">"Barkley, Erik J (3970)" <<a href="mailto:erik.j.barkley@jpl.nasa.gov">erik.j.barkley@jpl.nasa.gov</a>></span>
<br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">To: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif"">"Chamoun, Jean-Pierre (GSFC-458.0)[Affiliate] (<a href="mailto:jean-pierre.chamoun@nasa.gov">jean-pierre.chamoun@nasa.gov</a>)"
<<a href="mailto:jean-pierre.chamoun@nasa.gov">jean-pierre.chamoun@nasa.gov</a>>, "<a href="mailto:Marcin.Gnat@dlr.de">Marcin.Gnat@dlr.de</a>" <<a href="mailto:Marcin.Gnat@dlr.de">Marcin.Gnat@dlr.de</a>>, "<a href="mailto:Colin.Haddow@esa.int">Colin.Haddow@esa.int</a>"
<<a href="mailto:Colin.Haddow@esa.int">Colin.Haddow@esa.int</a>>, "<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>" <<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>>,
</span><br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">Cc: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif"">CCSDS Service Mgmt WG <<a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a>></span>
<br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">Date: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif"">01/07/2015 03:38</span>
<br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">Subject: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif"">Abstract service request telecon notes</span>
<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" noshade="" style="color:#A0A0A0" align="center">
</div>
<p class="MsoNormal"><br>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">Colin, Marcin, JP, Holger,</span>
<br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif""> </span> <br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">Attached are the notes from our June 30 splinter session teleconference on engineering an abstract service request. The notes have also been uploaded to the CWE. Corrections and/or comments appreciated.</span>
<br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif""> </span> <br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">Best regards,</span>
<br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif""> </span> <br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">-Erik[attachment "2015-06-30-AbstractSvcReq-TeleconferenceNotes.docx" deleted by Holger Dreihahn/esoc/ESA]
</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>
</div>
</body>
</html>