<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>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:"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:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{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:2141336654;
mso-list-template-ids:-2125434716;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
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=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hi Felix,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks again for keeping this dialogue going. The more that we can all communicate with the intent to reach a common understanding the better off we will all be.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>FRM – I agree completely that the FRM, with some suitable broadening of focus, should be able to describe abstract protocol functions in space just as it does on for ground stations. In fact, it should also serve equally well for any protocol functions within an MOS.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>EDS – since these are intended to describe interfaces of fully realized components, whether hardware of software, I also agree that they should be as useful on the ground as they are in space deployment. Here too, however, they may require some broadening of focus and some new interface bindings. That said, at the protocol level I do not believe that the EDS and DOT provide anything other than the means to describe the PDUs that get emitted at the interfaces of spacecraft devices that spacecraft on-board comm links.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>So I would agree that implementations, per se, will continue to be agency (or vendor) specific, but that <b>interoperable descriptions</b> of the interfaces of these components can be produced with EDS and DOT, after any necessary new binding types are added to the DOT.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>For CSTS MD & SC I do not see how these can be generalized for use in space, but I do agree that the FRM set, and the functionality that MD and SC offer, can be expanded to cover DTN related services and components on the ground. I do not think that the MD-CSTS and SC-CSTS can be generalized for use in space deployments.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>In contrast, I do believe that the AMA / ADM standards that are being defined in the IETF for use with DTN can be used both in space and terrestrially. They are defined to be used in an asynchronous mode and with potentially delayed delivery or in disconnected environments. So they are immune to the usual issues related to delay and disconnection. Based on the analysis I have done, I believe that the issue with using AMA and ADM is that right now they only offer reporting and monitor data delivery, they do not (yet) offer DTN network management in any sort of active control sense, and they are not yet well secured.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>In fact, the whole issue of how to secure communications, and to secure the network and its management, in a multi-agency interoperable way is still very much in discussion. There are security mechanisms built into BPv7 and BPSec, and these support encryption, authentication, and both together. Using these to manually secure communications is possible. These features can be used, as is, with pre-emplaced keys and relying upon pre-determined, and implicitly trusted, “identities” of participating nodes and users. The problem, to my way of thinking, is that there is as yet no established and formalized way to define and use unimpeachable identities of communicating nodes and other entities that participate in communications, for configuration, control, and reporting on any sort of multi-agency network.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I just gave a presentation to the CMC that detailed the concepts that I have been exploring about how to secure the future CCSDS DTN functions. It was well received and it had review by several of the CCSDS Security and DTN experts. This is conceptual, and much more work needs to be done to make it a reality, but I offer it up here for consideration and to request feedback. Perhaps we can use this as a sort of conceptual framework around which we can formulate the specific standards that we agree are needed to reach a viable, secure, future multi-agency DTN deployment.<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><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><b><span style='font-size:12.0pt;color:black'>From: </span></b><span style='font-size:12.0pt;color:black'><Felix.Flentge@esa.int><br><b>Date: </b>Wednesday, December 15, 2021 at 5:43 AM<br><b>To: </b>Peter Shames <peter.m.shames@jpl.nasa.gov><br><b>Cc: </b>Erik Barkley <erik.j.barkley@jpl.nasa.gov>, "Holger.Dreihahn@esa.int" <Holger.Dreihahn@esa.int>, John Pietras <john.pietras@gst.com>, "Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot@nasa.gov>, Keith Scott <kscott@mitre.org>, Ramon Krosley <r.krosley@andropogon.org>, SEA-SA <sea-sa@mailman.ccsds.org>, Tim Pham <timothy.t.pham@jpl.nasa.gov>, "Tomaso.deCola@dlr.de" <Tomaso.deCola@dlr.de><br><b>Subject: </b>Re: [EXTERNAL] Re: [Sea-sa] Second cut at CSS FRM and SOIS EDS integration approach<o:p></o:p></span></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Thanks Peter,</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>yes, makes sense to me and seems to be a pragmatic way forward:</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>- FRM providing a way to describe parameters, directives and events (I think it is something we will should do for ground nodes anyway and I would expect space nodes to be very similar).</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>- specific implementation could be agency-specific initially (based on EDS or not) until a inter operable protocol is defined (for terrestrial use we could even use CSTS Monitored Data / Control during that time) </span><br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>The security topic is, of course, a major one and it keeps coming up in different contexts again and again (Mars communication, Lunar Communication Networks). We are currently discussing internally how to address it and will come forward with some proposal.</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Regards,</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Felix</span> <br><br><br><br><br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>From: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>"Shames, Peter M (US 312B)" <peter.m.shames@jpl.nasa.gov></span> <br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>To: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>"Felix.Flentge@esa.int" <Felix.Flentge@esa.int></span> <br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>Cc: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>"Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot@nasa.gov>, "Ramon Krosley" <r.krosley@andropogon.org>, "Barkley, Erik J (US 3970)" <erik.j.barkley@jpl.nasa.gov>, "Holger.Dreihahn@esa.int" <Holger.Dreihahn@esa.int>, "EXTERNAL-Pietras, John V (US 332C-Affiliate)" <john.pietras@gst.com>, "Pham, Timothy T (US 3300)" <timothy.t.pham@jpl.nasa.gov>, "Keith Scott" <kscott@mitre.org>, "Tomaso.deCola@dlr.de" <Tomaso.deCola@dlr.de>, "SEA-SA" <sea-sa@mailman.ccsds.org></span> <br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>Date: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>13/12/2021 23:19</span> <br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>Subject: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>Re: [EXTERNAL] Re: [Sea-sa] Second cut at CSS FRM and SOIS EDS integration approach</span> <o:p></o:p></p><div class=MsoNormal align=center style='text-align:center'><hr size=0 width="100%" noshade style='color:#A0A0A0' align=center></div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><p style='margin:0in'>Hi Felix,<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>Thanks for engaging in this discussion. It is really important to get diverse viewpoints heard, so I appreciate it.<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>Glad you found the FRM and EDS discussion to be useful. When I dug into this there was clearly an overlap, or at least a point where they “touch”, but I think they are sufficiently separate in purpose, and yet aligned at “touch points”, that we can just integrate them by using the same terms in the same way where appropriate. <o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>On the matter of the MIB, I agree that these are “protocol parameters”, but in many cases these also directly control and configure protocol behavior. <o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>The SAPs are almost always left off of these diagrams unless we are trying to specifically address topics relevant to the SAP itself. Since a SAP is essentially just a sort of abstract API, and we do not usually define APIs, they can safely be ignored for most protocol design & deployment purposes. The CLA’s, when and where they are defined, are one way of handling this in a concrete form.<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>On the whole AMA /ADM topic I think there is a longer discussion. I just read the whole AMA, ADM, AMM, ADMT, ODM, AMP, ADM Agent, etc, etc, story. I THINK I understand what they are trying to do, but I need to check my assumptions with the SIS DTN WG and Ed Birrane. Most of the functionality seems to be focused upon asynchronous management and reporting of remote, “agents” of one form or another. The fundamental aspects defined so far seem to be mostly about controlling the reporting from the agents, so many bundles processed, lost, etc. I have not seen anything (yet) that addresses routing updates, potential contact plan exchange, pointing / orbit updates, or the exchange of any other control artifacts like ACLs. I think that the AMA / ADM has features that might be able to handle this, or that the core can be extended in this way, but as far as I can tell these operations and controls have not yet been defined. <o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>Security is weakly described and yet I think it is essential to secure the management interfaces that will provide these space internetworking services.<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>That said, as far as the functional components that will be needed inside a space (or ground) entity that supports a Bundle Agent, link layer services, or an ADM for that matter, I agree that the FRM provides an excellent framework for this. I think that, just as with the link layer functions, all of these protocol elements for the DTN, LTP, ADM, etc, can be most suitably modelled using the CSS FRM features and tool set. And, once these FRM are defined, and they get implemented inside some set of components, that we could then use the SOIS EDS to define the interfaces of those components. <o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>I think it all hangs together, but I would like to get verification of this from others. And I would like to get a better understanding of just what we might be able to do vis-à-vis extending the existing AMA / ADM concepts to cover more of the whole DTN secure network management needs.<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>Does this make sense to you?<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>Thanks again.<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'>Peter<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'><b><span style='font-size:12.0pt'>From: </span></b><span style='font-size:12.0pt'><Felix.Flentge@esa.int><b><br>Date: </b>Monday, December 13, 2021 at 4:23 AM<b><br>To: </b>Peter Shames <peter.m.shames@jpl.nasa.gov><b><br>Subject: </b>[EXTERNAL] Re: [Sea-sa] Second cut at CSS FRM and SOIS EDS integration approach</span><o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Dear Peter,</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'><br>thanks for sorting out the differences between the EDS and the FRM. It's very useful and clarified some things for me.</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'><br>Regarding the AMA/ADM stuff and looking at the discussions in the IETF DTN WG on its re-charter, I am not sure whether this will be taken up. The current draft charter (</span><a href="https://datatracker.ietf.org/doc/charter-ietf-dtn/"><span style='font-size:12.0pt'>Delay/Disruption Tolerant Networking (ietf.org)</span></a><span style='font-size:12.0pt'> </span><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>) includes Network Management (or rather Operations, Administration and Management) but it does not commit to AMA and, in general, it seems a long way to go.</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'><br>For the up-coming IOAG Mars Communication Architecture (to be released soon), the way forward will probably be to suggest FRM for internal DTN network management until a time when DTN Network Management will be fully defined. I do believe that this would be a viable and sensible way forward.</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'><br>One minor comments to your slides: slides 4 & 5 describe the MIB as describing 'Protocol controls'. The MIBs I have encountered at CCSDS (CFDP, BP) do usually describe only 'protocol parameters'. I think the, Service Access Point (SAP) with requests/indications may be missing in these figures.</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'><br>Regards,<br>Felix</span> <br><br><b><span style='font-size:8.0pt;font-family:"Verdana",sans-serif;color:gray'><br>_________________________________________</span></b> <b><span style='font-size:8.0pt;font-family:"Verdana",sans-serif;color:gray'><br>ESA - European Space Agency </span></b><span style='font-size:8.0pt;font-family:"Verdana",sans-serif;color:#00A1E0'><br>Dr. Felix Flentge</span><span style='font-size:8.0pt;font-family:"Verdana",sans-serif;color:gray'><br>Software Engineer, OPS-GSB<br>Ground Systems Engineering Department<br>Directorate of Operations</span> <b><span style='font-size:8.0pt;font-family:"Verdana",sans-serif;color:gray'><br>ESA - ESOC</span></b><span style='font-size:8.0pt;font-family:"Verdana",sans-serif;color:gray'><br>Robert-Bosch-Str.5, D-64293 Darmstadt, Germany</span> <span style='font-size:8.0pt;font-family:"Verdana",sans-serif;color:gray'><br>Phone: +49 6151 90 4075 | Email: Felix.Flentge@esa.int</span> <br><br><br><br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'><br>From: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>"Shames, Peter M\(US 312B\) via SEA-SA" <sea-sa@mailman.ccsds.org></span> <span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'><br>To: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>"Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot@nasa.gov>, "Ramon Krosley" <r.krosley@andropogon.org>, "Barkley, Erik J (US 3970)" <erik.j.barkley@jpl.nasa.gov>, "Holger.Dreihahn@esa.int" <Holger.Dreihahn@esa.int>, "EXTERNAL-Pietras, John V (US 332C-Affiliate)" <john.pietras@gst.com></span> <span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'><br>Cc: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>"Tomaso.deCola@dlr.de" <Tomaso.deCola@dlr.de>, "Pham, Timothy T\(US 3300\)" <timothy.t.pham@jpl.nasa.gov>, "Keith Scott" <kscott@mitre.org>, "SEA-SA" <sea-sa@mailman.ccsds.org></span> <span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'><br>Date: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>09/12/2021 23:30</span> <span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'><br>Subject: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>[Sea-sa] Second cut at CSS FRM and SOIS EDS integration approach</span> <span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'><br>Sent by: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>"SEA-SA" <sea-sa-bounces@mailman.ccsds.org></span> <o:p></o:p></p><div class=MsoNormal align=center style='text-align:center'><hr size=0 width="100%" noshade style='color:#A0A0A0' align=center></div><p style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:2.5in;margin-left:0in'> <o:p></o:p></p><p style='margin:0in'><span style='font-size:12.0pt'>Guys,</span><o:p></o:p></p><p style='margin:0in'><span style='font-size:12.0pt'> </span><o:p></o:p></p><p style='margin:0in'><span style='font-size:12.0pt'>I sent and earlier version of this file out a while ago, and just refined it. I cleaned up some of the terminology use and also added a couple of new “here’s what it would look like to use FRM to describe the protocol innards of SOIS on-board communications components” diagrams. See pgs 13-14. I did not create a separate diagram to describe the use of EDS to define ESLT <b><i>real component</i></b> interfaces, but that is pretty straightforward.</span><o:p></o:p></p><p style='margin:0in'><span style='font-size:12.0pt'> </span><o:p></o:p></p><p style='margin:0in'><span style='font-size:12.0pt'>Please take a look at this stuff and let’s get it right.</span><o:p></o:p></p><p style='margin:0in'><span style='font-size:12.0pt'> </span><o:p></o:p></p><p style='margin:0in'><span style='font-size:12.0pt'>Meanwhile I am off working to understand the whole thicket of SIS AMA, ADM, ADMT, ODM standards and how they play with DTN, BP, BPSec, etc. As far as I have dug into it so far, it appears that the AMA/ADM stuff is really a sort of data model and control language for control of applications and protocols. As stated in the AMA doc, [I-D.birrane-dtn-ama]:</span><o:p></o:p></p><p style='margin:0in'><span style='font-size:12.0pt'> </span><o:p></o:p></p><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>The Asynchronous Management Architecture (AMA) defines a concept for the open-loop control of applications (and protocols) in situations where timely, highly-available connections cannot exist amongst managing and managed nodes in a network. <o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>While the AMA provides a logical data model, it does not include the detailed information necessary to produce interoperable data models. <o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>The ADM defines a physical data model suitable for managing applications in accordance with the AMA. This physical model is termed the Asynchronous Management Model (AMM) and consists of the data types and data structures needed to manage applications in asynchronous networks. <o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>The ADM document also provides a template, called the Application Data Model Template (ADMT), for the standardized representation of application-specific instances of this model. Using the types and structures defined by the AMM, individual applications can capture their unique, static management information in documents compliant with the ADMT. These application-specific documents are called Application Data Models (ADMs).<o:p></o:p></li></ul><p class=MsoNormal> <o:p></o:p></p><p style='margin:0in'><span style='font-size:12.0pt'>I have read the AMA and ADM, cover-to-cover, but have not yet dug down through the AMM and ADMT, I am not yet seeing the relationship of this AMA/ADM to either the EDS or the FRM since it does not appear to reference either components nor interfaces. If anything, the relationship might be between the AMM/ADM and the CSS SM and MD/SC standards. We’ll see.</span><o:p></o:p></p><p style='margin:0in'><span style='font-size:12.0pt'> </span><o:p></o:p></p><p style='margin:0in'><span style='font-size:12.0pt'>Feedback please, on this part.</span><o:p></o:p></p><p style='margin:0in'><span style='font-size:12.0pt'> </span><o:p></o:p></p><p style='margin:0in'><span style='font-size:12.0pt'>Thanks, Peter</span><o:p></o:p></p><p style='margin:0in'><span style='font-size:12.0pt'> [attachment "SEA Protocol FRM EDS model comparison 211209.pptx" deleted by Felix Flentge/esoc/ESA] </span><span style='font-size:10.0pt;font-family:"Courier New"'>_______________________________________________<br>SEA-SA mailing list<br>SEA-SA@mailman.ccsds.org</span><u><span style='font-size:12.0pt;color:blue'><br></span></u><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa"><span style='font-size:10.0pt;font-family:"Courier New"'>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa</span></a><o:p></o:p></p></div></body></html>