<html 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)">
<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:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="#467886" vlink="#96607D" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Dear SEA SAWG, RASDSv2 subset,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">We have good news and not quite so good news. The good news is that the RASDSv2 was, in general, well received. The not so good news is that the CESG identified some issues that they wish to resolve before
publication. There is good news buried in here too (call me an optimist), because I do not believe that any of these is too onerous to resolve fairly easily. See attached.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The focus for the next “second Monday of the month” SEA SAWG meeting will be agreeing on the resolution of these PIDs. I will work up draft responses for discussion. I’d like to get this wrapped up in Dec
if possible.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Best regards, Peter<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="color:black">From:
</span></b><span style="color:black">CCSDS Secretariat <thomas.gannett@tgannett.net><br>
<b>Date: </b>Wednesday, November 20, 2024 at 9:31</span><span style="font-family:"Arial",sans-serif;color:black"> </span><span style="color:black">AM<br>
<b>To: </b>Shames, Peter M (US 9740) <peter.m.shames@jpl.nasa.gov><br>
<b>Cc: </b>Barkley, Erik J (US 3970) <erik.j.barkley@jpl.nasa.gov>, Ignacio.Aguilar.Sanchez@esa.int <Ignacio.Aguilar.Sanchez@esa.int><br>
<b>Subject: </b>[EXTERNAL] Re: CESG-P-2024-10-005 Approval to publish CCSDS 311.0-M-2, Reference Architecture for Space Data Systems (Magenta Book, Issue 2)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt">Dear Document Rapporteur,<br>
<br>
The CESG poll to approve publication of CCSDS 311.0-M-2, Reference Architecture for Space Data Systems (Magenta Book, Issue 2) concluded with conditions. Please negotiate disposition of the conditions directly with the AD(s) who voted to approve with conditions
and CC the Secretariat on all related correspondence.<br>
<br>
<br>
CESG E-Poll Identifier: CESG-P-2024-10-005 Approval to publish CCSDS 311.0-M-2, Reference Architecture for Space Data Systems (Magenta Book, Issue 2)<br>
<br>
Results of CESG poll beginning 29 October 2024 and ending 19 November 2024:<br>
<br>
Abstain: 0 (0%) <br>
Approve Unconditionally: 2 (50%) (Shames, Cola)<br>
Approve with Conditions: 2 (50%) (Barkley, Aguilar Sanchez)<br>
Disapprove with Comment: 0 (0%) <br>
<br>
CONDITIONS/COMMENTS:<br>
<br>
Erik Barkley (Approve with Conditions): 1. Section 1.3, re the text "...can, and have, been directly adopted for use with the UML and SysML representations that are provided by typical Model Based Systems Engineering (MBSE) tools" can references
regarding the "directly adopted for use" be provided? Perhaps as a footnote? <br>
<br>
2. Figure 2-4 -- can this be cleaned up? At least get the text to fit in the boxes (Metamodel, Environment), and not have the arrows slice through the text (e.g. it says "Offers" from Function to Service but it is not really clear). It should be possible
to move the text or arrows sufficiently so that all is clear. <br>
<br>
3. Figure 2-4 -- what is meant by "prop" in Component Node, Connector (Link)?
<br>
<br>
4. Figure 3-1 -- Are the textual element for the "Logical Link between Elements" required for this icon? (these are "Service Consumer, Data, Service Provider") -- it seems this is an example application of the icon, not the icon "definition"? I will
note that the box with "Data" tends to make sense as part of the icon definition. Perhaps "Service Consumer" and "Service Provider" should read Object A and Object B?
<br>
<br>
5. Figure 3-4 -- consider changing the term "Main Object” to just simply " Object". rationale: this more readily supports the composition of an object by other objects as opposed to a composition of a main object by other main objects and I think is
more in line with what the diagram is showing. (Does RASDS distinguish between "main object” and "object"?) I think the change will make this figure more consistent with Figure 6-2 (which does not have a "main component", but just components)<br>
<br>
6. Figure 4-6 -- could use some cleaning (reference comment on figure 2-4 -- also, the little cartoon figures with thought and speech bubbles -- are these part of RASDS? If not does RASDS recommend these kinds of embellishments? ( to be clear, they do
help, but I'm just trying to sort out what is actually RASDS versus what is not)
<br>
<br>
7. Annex C-- I am not sure that this add anything very useful. Reading through it, it appears more to be a tutorial on SYSML than actually showing anything on RASDS. Perhaps what could make this more useful is to show the RASDS equivalent for the
SYSML diagrams shown . Presumably the RASDS diagrams would be more succinct? As is, I don't really see that this adds anything to elucidate or otherwise define RASDS -- perhaps remove?<br>
<br>
I also noted an 8th point:<br>
<br>
8. Figure C-4 – comments/TODO list regarding review with Mike Anderson may not be the most appropriate for a formal CCSDS document publication?<br>
<br>
<br>
Ignacio Aguilar Sanchez (Approve with Conditions): </span><span style="font-size:11.0pt;font-family:"Arial",sans-serif"></span><span style="font-size:11.0pt">After a more detailed reading of the document, I am revising my vote. There are a few points
that in my opinion would need to be addressed before publication.<br>
<br>
1. In section 1.4, page 1-3, three additional viewpoints are introduced with respect to the previous version of the document. SInce the more viewpoints, the more complex the architecture description, it is in my view crucial to explain why additional viewpoints
are needed. In this respect, it is stated that they are there to support the needs of ISO TC20/SC14. A search for related definitions in ISO OBP indicated that only the Physical Viewpoint is defined by ISO, which begs the question about the origin of the other
two viewpoints (Services, Operational). Where are they coming from?<br>
<br>
2. In section 2.3.2, the derivation of the Connectivity and Structural Viewpoints from the new Physical Viewpoint is introduced. However, it is not explained why they were needed.<br>
<br>
</span><span style="font-size:11.0pt;font-family:"Arial",sans-serif"></span><span style="font-size:11.0pt">3. The current definition of "viewpoint" in 3.2.5, page 3-5 is recursive, citing the term to be defined in the definition. A search on ISO OBP, even
filtering for the relevant technical domain, provided way too many hits to be able to propose a solid definition. In some of those hits, the "architecture viewpoint" is equated to "viewpoint".<br>
<br>
<br>
Total Respondents: 4<br>
<br>
No response was received from the following Area(s):<br>
<br>
MOIMS<br>
SOIS<br>
<br>
<br>
<br>
SECRETARIAT INTERPRETATION OF RESULTS: Approved with Conditions<br>
PROPOSED SECRETARIAT ACTION: Generate CMC poll after conditions have been addressed<br>
<br>
* * * * * * * * * * * * * * * * * * * * * * * *<br>
<br>
<br>
<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>