<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=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style id=owaParaStyle>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:"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:"Calibri Light";
panose-1:2 15 3 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:11.0pt;
font-family:"Calibri",sans-serif;}
h1
{mso-style-priority:9;
mso-style-link:"Heading 1 Char";
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:24.0pt;
font-family:"Calibri",sans-serif;
font-weight:bold;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.Heading1Char
{mso-style-name:"Heading 1 Char";
mso-style-priority:9;
mso-style-link:"Heading 1";
font-family:"Calibri Light",sans-serif;
color:#2F5496;}
p.msonormal00, li.msonormal00, div.msonormal00
{mso-style-name:msonormal0;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.gfidiscscisyscouk, li.gfidiscscisyscouk, div.gfidiscscisyscouk
{mso-style-name:gfidiscscisyscouk;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msochpdefault, li.msochpdefault, div.msochpdefault
{mso-style-name:msochpdefault;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
span.emailstyle19
{mso-style-name:emailstyle19;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.emailstyle20
{mso-style-name:emailstyle20;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.heading1char0
{mso-style-name:heading1char;
font-family:"Calibri Light",sans-serif;
color:#2F5496;}
span.emailstyle24
{mso-style-name:emailstyle24;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle28
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.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;}
/* List Definitions */
@list l0
{mso-list-id:921640012;
mso-list-template-ids:1692284276;}
@list l0:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:1759133727;
mso-list-template-ids:1692284276;}
@list l1:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">Hi Richard,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks for taking the time to review and provide these comments. I also want to state at the outset that I understand that without support to do this you cannot take on more work. Assuming that the team agrees, my intent is to get to
consensus on the needed changes using this Excel spreadsheet approach and then to update the document myself, seeking support and feedback from the combined team.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">You question about services and bindings is a really good one and I agree that it appears to be an on-going point of confusion. CCSDS has tried to address this in RASDS, MO, and SLE (in particular) in the following ways:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">object (RASDS 311.0-M-1): <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">An object is an abstract model of an entity in the real world. It contains information, has behavior, and may offer services. A system is composed of interacting objects. An object is characterized by that which
makes it distinct from other objects. <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Interface (RASDS 311.0-M-1): <o:p>
</o:p></p>
<p class="MsoNormal" style="margin-left:.5in">A set of interactions performed by an object for participation with another object for some purpose, along with constraints on how they can occur. An interface is therefore where the behavior of an object is exposed.
Objects may have one or more interfaces.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">service (RASDS 311.0-M-1): <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">A service is a provision of an interface of an object to support actions of another object.
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Cross support service (RASDS 311.0-M-1):
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Cross-support service interfaces are really just the exposed set of interfaces of applications layer Engineering Objects. All application Engineering Objects have interfaces; the ones that are exposed between facilities
owned and operated by (the same or) different Enterprises are called cross-support service interfaces.
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">service interface (MO Ref Model 520.1-M-1):<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">A set of interactions provided by a component for participation with another component for some purpose, along with constraints on how they can occur. A Service Interface is an external interface of a Service where
the behaviour of the Service Provider Component is exposed. Each Service will have one defined ‘Provided Service Interface’, and may have one or more ‘Consumed Service Interface’ and one ‘Management Service Interface’.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">abstract service (SLE 910.2-G-1):<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">A set of capabilities that one abstract-object offers to another by means of one or more of its abstract-ports.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">communications service (SLE 912.3-B-2, and others):<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">A capability that enables an SLE service-providing application entity and an SLE service-using application entity to exchange information.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">OSI services (SLE 910.2-G-1):<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">The capability of an OSI-service-provider to OSI-service-users at the boundary between the OSI-service-provider and the OSI-service-users.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">provided service interface (MO Ref Model 520.1-M-1):<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">A Service Interface that exposes the Service function contained in a component for use by Service Consumers. It receives the MAL messages from a Consumed Service Interface and maps them into API calls on the Provider
component.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">service access point (RASDS 311.0-M-1):
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">The point at which (N-layer)-services are provided by an (N-layer)-protocol-entity to an (N+l-layer)-protocol-entity.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">service interface (MO Ref Model 520.1-M-1):<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">A set of interactions provided by a component for participation with another component for some purpose, along with constraints on how they can occur. A Service Interface is an external interface of a Service where
the behaviour of the Service Provider Component is exposed. Each Service will have one defined ‘Provided Service Interface’, and may have one or more ‘Consumed Service Interface’ and one ‘Management Service Interface’.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">service provider (SLE 910.4-B-2, and others):<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">An entity that offers a service to another by means of one or more of its ports.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I'm including all of these different, but related, definitions to make a point. We have been trying really hard to bring a level of consistency to the CCSDS standards and their uses of terms. I'd say we have only partly succeeded. One
thing to keep in mind is that RASDS was intended to provide as set of (largely abstract) terms that were consistent and could be broadly used. It also provides a set of defined viewpoints from which systems could be described and addressed how these different
views are related. This kind of precision has not been not always been adhered to across CCSDS, and as a result we get some "leakage" in the definitions and also need to identify for ourselves just which views are being addressed at any given point. It is
also the case that individual standards will often specialize their definitions, we see that in the MAL and SLE definitions.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Depending on where one stands an "interface" may be some software thing (an API), a hardware thing (Ethernet), a protocol thing (TCP/IP & socket), exposed inside a system for local use (software bus) or exposed outside a system (SLE).
I tend to think of interfaces as all of these things and have worked to define a way to model all of these aspects in relationship one to another. I'm attaching an MBSE paper I jointly wrote about this that was published in INCOSE in 2016. It carefully (I
think) lays out how to model all of these parts in relationship one to another. The future update to RASDS will add MBSE considerations and reference these materials.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Enough of definitions and pedantics, now to the details that show up in your note. See below,
<span style="color:#0070C0"><<in-line>></span>.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks, Peter<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Richard Melvin <Richard.Melvin@scisys.co.uk><br>
<b>Date: </b>Monday, October 29, 2018 at 6:28 AM<br>
<b>To: </b>Peter Shames <Peter.M.Shames@jpl.nasa.gov>, SEA-SA <sea-sa@mailman.ccsds.org><br>
<b>Cc: </b>Sam Cooper <sam@brightascension.com><br>
<b>Subject: </b>RE: Request for SEA-SA review of SOIS / MOIMS analysis document<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">Ok, now I can read the comments.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">Mostly makes sense to me, the required changes seem to be all doable.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">A couple of points of understanding:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">1. services and binding<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">In RASDS and/or MO terminology, a 'service' is an abstract definition which gets given a 'binding' to a particular 'component', 'port' and
'technology' and then becomes an 'interface'.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0"><<Components have interfaces. Components have behavior (in the application / function sense). Interfaces have bindings to particular port, technology, and a protocol stack). Each protocol in the stack has
PDU, interactions "on the wire", and behaviors (at the protocol level) within the protocol entities. The top level protocol in the stack, and the binding interface, is the one that exhibits the behavior at that interface.>><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">In existing SEDS terminology (taken from ESA SAVOIR):<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">- an 'interface definition' is an abstract thing that speciifies a specific pattern of message exchange<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0"><<This is a very limited definition of "interface", since it appears to assume "messages" and "message exchange". I think SOIS overall is broader than this. This sounds like a software kind of message abstract
view at application layer. Right?>></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">- when bound to a particular component type and port ('name', in the schema), but not technology, it becomes an 'instance' of that definition,
or just an 'interface'<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0"><<Talking about an interface of a component, and a port, in the absence of technology, sounds like a very limited view of an interface. It is not that you cannot limit discussion to these sorts of software views,
but it is the case that "interface" is much broader than that, and at some point you really need to understand the rest, behavior, protocol stack, all the way down to physical bindings for hardware components and the allocation of software components to hardware
components.>></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">- a 'service' is more abstract still; it defines the goals or requirements of a pattern of message exchange, but doesn't necessarily specific
the actual patterns or messages.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#0070C0"><< This is also a very limited definition of "interface", since it appears to assume "messages" and "message exchange">></span><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">So device component 'StarTracker' provides a 'Attitude' interface definition under the name 'currentAttitude'. And that is an example of
a 'device access' service.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0"><<This "Device Access service" is an abstraction of a specific device, making reference to a specific abstracted data item. It hides all the real details of the device and the real attributes and physical interface
behind some software layer. If this is what we mean by "Device Access Service" then we're on common ground. But any such "service" is going to present a different interface depending on other factors, such as the nature of the "message bus", the nature of
the actual device (real counts vs engineering units), and the nature of the real device interfaces, 1553 vs spacewire vs RS422 vs LVDS vs TTEthernet). Right?<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#0070C0">The strength of EDS, as I understand it, is that you can talk in this abstract fashion about the provided service from the real device, and about the real physical connections, and use the EDS to autogenerate
the mappings.>><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">Binding of non-subnetwork interfaces to a technology is not something SEDS attempts to address; you can use calls in a programming language,
message passing, or whatever. But naiive C++ code would be something like:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#0070C0"><<Interesting statement. I would think that EDS would want to be able to specify these bindings all the way from the S/W abstractions down to the physical layer, or down to a message bus or other "layer". It's
fair enough to say "the Subnetwork WG will handle those grimy details.", but then you are assuming that those guys expose a consistent interface across all underling subnetworks AND that the only thing that EDS can handle is subnets that have such a specification.
This strikes me as being a rather limited approach, but it's your (collective) choice.>><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">class StarTracker <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">{<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"> Attitude * currentAttitude;<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">}<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">Binding to subnetwork technologies is one of the jobs of the subnetwork WG; so far only Spacewire has been covered. Or of course you could
use a mission-specific or local-standard binding.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">Is that all correct?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">If so, in an ideal world, I'd be keen to change 'Interface definition' to 'service', and use 'service class' or
</span><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">omething<span style="color:black"> for the cases where that is distinct from simple 'service'. <o:p></o:p></span></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">But I think that would have to be judged quite a high priority to be worth the documentation and example changes now.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#0070C0"><< I think I would council sticking to "interface" and adequately specifying (and constraining) just what it is that you are talking about, SW, message bus, "subnet", physical, etc". I do not think that all
of these things are services in any sense of the term.>></span><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">2. the three stages <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">The document currently only considers stages 1 and 3; the approach of a 'hybrid' architecture where some MO services are onboard and some
on the ground was not considered. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">In particular, the use of onboard MO is assumed to mean the use of onboard MO-based commanding and parameters.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#0070C0"><<So you are asserting that both fig 5-1 and fig 5-3 are Case 3 examples. In looking at this more closely I can see that you could make that claim. I think we need some comparable Case 2 example. As we were
discussing this in the SAWG we thought that Case 2 would involve what we called an "MO Proxy" on-board which would accept "MO commanding and parameters", and provide "MO responses", but would otherwise be a "normal" real-time, on-board, resource constrained
environment. In such an environment you would still have more typical GNC, M&C, C&DH, FDIR, power & thermal management, etc in control.>><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">For example, a MO onboard scheduler application should, as I understand it, be layered on top of the MO action service to actually do the
things it needs to do. And a planner probably layered on top of that.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">I am not actually convinced such a hybrid is viable; it would mean either:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">- onboard MO applications sending messages to the ground to ask the MO gateway to request the execution of a command<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">- losing centralised coherency over operational concepts like 'what commands have been executed' and 'can a command be executed now?'<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">- having the ground gateway operate at a higher logical layer than previously presented<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#0070C0"><<I know that we have migrated some amount of higher level GNC and even science analysis on-board. We have also migrated higher level autonomous behaviors. But all of this has occured on an underlying RT, OB,
RC framework, and not some GDS framework that takes over the flight system.>><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">Addressing those concerns is the kind of thing a presentation of such a model should do. While no doubt someone should do that, I don;t
see how I can do so.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">Richard<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0"><<Let's see if we can get to a viable middle ground. Without requiring major new work. I think all of this is still evolving and we only need to point to a way to make the best use of capabilities in the environments
in which they are best suited.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0">Thanks, Peter<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#0070C0">>><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
<div>
<div class="MsoNormal" align="center" style="margin-left:.5in;text-align:center">
<span style="font-family:"Times New Roman",serif;color:black">
<hr size="0" width="100%" align="center">
</span></div>
<div id="divRpF526178">
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
<b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"> Shames, Peter M (312B) [Peter.M.Shames@jpl.nasa.gov]<br>
<b>Sent:</b> 26 October 2018 6:41 PM<br>
<b>To:</b> Richard Melvin; SEA-SA<br>
<b>Cc:</b> Sam Cooper<br>
<b>Subject:</b> Re: Request for SEA-SA review of SOIS / MOIMS analysis document</span><span style="font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">Dear Richard, et al,</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">I could not find a straightforward way to make these comments visible in the exported PDF, except within the Mac Preview app. Happily that document still contained (almost all) of my comments
in a form where I could easily extract them.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">As a result of this PDF compatibility issue I have gone crawling through the PDF document and extracted the attached set of comments and responses, represented now in an Excel spreadsheet.
I put in page and section references and these are in the same order as the original. If you want to see exactly what any inputs relate to you will have to follow the bouncing balls from the PDF to the spreadsheet.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">As noted before there are three kinds of notes in the document:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in;text-indent:-.25in;mso-list:l1 level1 lfo1">
<![if !supportLists]><span style="color:black"><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="color:black">Notes that show up as a white square came from MOIMS, apparently Mario Merri<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in;text-indent:-.25in;mso-list:l1 level1 lfo1">
<![if !supportLists]><span style="color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="color:black">Notes that show up as a yellow square with a "thought bubble" also came from MOIMS, apparently Mehran Sarkarati<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in;text-indent:-.25in;mso-list:l1 level1 lfo1">
<![if !supportLists]><span style="color:black"><span style="mso-list:Ignore">3.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="color:black">Notes that show up as a </span>
<b><span style="color:#FF40FF">magenta square</span></b><span style="color:black">, are comments from me (SEA) as to responses not requiring any changes and the rationale for this choice<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in;text-indent:-.25in;mso-list:l1 level1 lfo1">
<![if !supportLists]><span style="color:black"><span style="mso-list:Ignore">4.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="color:black">Notes that show up as a </span>
<b><span style="color:red">red square</span></b><span style="color:red"> </span><span style="color:black">are suggested changes to the draft document, many in response to MOIMS issues, some reflecting issues I found in reading the document<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">See if this works any better.</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">There is a column in the spreadsheet for SAWG Comments. Would each of you who choose to provide comments please use that column to indicate agreement, or not, and save a copy of the file
named to indicate who you are. <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">We will sort out any glaring disconnects in a telecon, as necessary.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">Thanks, Peter<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black"> <o:p></o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:1.0in"><b><span style="color:black">From:
</span></b><span style="color:black">Richard Melvin <Richard.Melvin@scisys.co.uk><br>
<b>Date: </b>Friday, October 26, 2018 at 4:16 AM<br>
<b>To: </b>Peter Shames <Peter.M.Shames@jpl.nasa.gov>, SEA-SA <sea-sa@mailman.ccsds.org><br>
<b>Cc: </b>Sam Cooper <sam@brightascension.com><br>
<b>Subject: </b>RE: Request for SEA-SA review of SOIS / MOIMS analysis document<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:black"> <o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:#1F497D">Thanks for doing the work on this.</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:#1F497D">Unfortunately, I couldn’t find a way to view the document comments in an offline PDF.
</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:#1F497D">Both adobe and foxit reader show the icons, but clicking on them does nothing and the comments it’s is empty.</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:#1F497D">Apologies if I am missing something stupid…</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:#1F497D">Richard</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:1.0in"><b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"> Shames, Peter M (312B) [mailto:Peter.M.Shames@jpl.nasa.gov]
<br>
<b>Sent:</b> 25 October 2018 22:49<br>
<b>To:</b> SEA-SA<br>
<b>Cc:</b> Sam Cooper; Richard Melvin<br>
<b>Subject:</b> Request for SEA-SA review of SOIS / MOIMS analysis document</span><span style="color:black"><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:black">Dear SAWG members,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:black">During the joint SAWG / MOIMS / SOIS meeting on Wednesday we spent quite some time discussing the draft document that SOIS produced comparing MO Services (based on the MAL) and SOIS EDS.
This is a Yellow Book, CCSDS 870.10-Y-0, titled "MO SERVICES AND SOIS ELECTRONIC DATASHEETS". The MOIMS AD identified a series of conditions that were written into the body of the PDF. It did not appear that the MOIMS and SOIS were going to reach agreement
on the disposition of these comments without some help, so I volunteered to provide an analysis on behalf of SEA. I want to enlist you in making sure that this is fair and balanced.
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:black">I am also adding Richard Melvin and Sam Cooper to this list, since Richard was the author of the document and Sam was the primary MOIMS point of contact. I ask them to put their "SAWG
hats on" and participate in as unbiased a way as they are capable of, while offering any technical clarity and accuracy is needed. In this they are supplemented, of course, by Roger and Ray.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:black">The first thing to say about this analysis is this:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.5in;text-indent:-.25in"><span style="color:black">1.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:black">
</span><span style="color:black">We have the ASL document and our own analyses and discussions of the suite of standards to draw upon<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.5in;text-indent:-.25in"><span style="color:black">2.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:black">
</span><span style="color:black">We have agreed, among ourselves and in this joint meeting, that there are three stages of MOIMS deployment into the on-board environment<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:black">Both of these are background and criteria for providing feedback. The three stages were stated during the joint meeting and they are repeated here for reference:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.5in;text-indent:-.25in"><span style="color:black">1.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:black">
</span><span style="color:black">SOIS device interfaces, subnets, and services on-board with the usual Real Time flight software and resource constraints, MOIMS only on ground, typical TT&C interfaces between them<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.5in;text-indent:-.25in"><span style="color:black">2.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:black">
</span><span style="color:black">Same SOIS services and RT FSW on-board, MOIMS Proxy interfaces to RT FSW on-board, "MAL" interfaces over TT&C<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.5in;text-indent:-.25in"><span style="color:black">3.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:black">
</span><span style="color:black">Same SOIS services and RT FSW on-board, MOIMS MAL adapted to RT environment and "standard" MOIMS services migrated on board as appropriate<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:black">Attached is the modified draft CCSDS 870.10-Y-0 document, in PDF form. It has three kinds of notes in it:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="color:black"><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="color:black">Notes that show up as a white square came from MOIMS<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.5in;text-indent:-.25in"><span style="color:black">2.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:black">
</span><span style="color:black">Notes that show up as a yellow square with a "thought bubble" also came from MOIMS</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.5in;text-indent:-.25in"><span style="color:black">3.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:black">
</span><span style="color:black">Notes that show up as a </span><b><span style="color:#FF40FF">magenta square</span></b><span style="color:black">, are comments from me as to responses and rationale<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.5in;text-indent:-.25in"><span style="color:black">4.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:black">
</span><span style="color:black">Notes that show up as a </span><b><span style="color:red">red square</span></b><span style="color:red">
</span><span style="color:black">are suggested changes to the draft document, many in response to MOIMS issues, some reflecting issues I found in reading the document<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:black">You will see that I recommend adding text to reflect the three stages we have agreed to, even though that is new material from the SAWG. I think it will help to clarify the options relating
to deployment. Some of the MOIMS comments attempt to push boundaries and I suggest that not be allowed. Existing scope, functions, and standards are to be respected. Some MOIMS comments propose on-board services, like MO compliant device interfaces, that
are very speculative. I think that they should be labelled as such since there are no MOIMS documents that can be referenced. The current work in SOIS to define use of EDS to document deployments of components and spacecraft configurations, however, is within
scope since they are actively working on that. I also found that this document, in general, is lacking a recognition of the importance of specifying interface bindings along with behaviors and data structures. I recommend that it gets added.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:black">Please review these MOIMS comments and my proposed dispositions. I would like to have your feedback in two weeks, by 9 November, if not sooner. This has dragged on long enough. Assuming
we can reach consensus I will then send the final result to the combined MOIMS and SOIS teams. I will provide final edits to the document in Word form once we have closure.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:black">While we are working together to reach consensus I ask that you all treat these materials, and the discussion, as SAWG internal work product.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:black">Thanks, Peter<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:black"> <o:p></o:p></span></p>
<p style="margin-left:.5in" id="gfidisc.scisys.co.uk"><span style="font-size:12.0pt;font-family:"Tahoma",sans-serif;color:blue"> </span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="font-family:"Arial",sans-serif;color:gray">SCISYS UK Limited. Registered in England and Wales No. 4373530.</span><span style="font-size:12.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="font-family:"Arial",sans-serif;color:gray">Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:green">Before printing, please think about the environment.</span><span style="color:black"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>