<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:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@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:2013025968;
mso-list-template-ids:-1033334846;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">Dear SCCS-ARD sub-group.</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">For this upcoming SCCS-ARD sub-group meeting, nominally scheduled for next Monday, 5 July, that day is a US Federal holiday so I am anticipating that few of the US colleagues will be willing to
participate. I’m expected them to be recovering for 4’th of July festivities. <o:p>
</o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><i><span style="font-size:12.0pt;color:black">I am asking that we move this meeting to Tuesday, 6 July 2021, at same time.<o:p></o:p></span></i></b></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">I’d like to spend some of that time reviewing the outcome of the coordination meeting we held with the leadership of the CCSDS Areas whose work we are describing in the ARD. Those notes are attached.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">I hope you can join us. Instead of Doodling for a new date/time I am going to just assume that we can get a quorum to attend. I hope that is the case.</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">Thanks, Peter</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> ===========================================================================================================================<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:black">Dear SLS, CSS, SIS, SEA, and SOIS colleagues,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">We just held a meeting to review the proposed set of changes that the SEA Systems Architecture WG (SAWG) is working on to revise the Space Communication Cross Support Architecture Requirements Document (CCSDS SCCS-ARD,
901.1-M-1). That document presently describes how more than fifty-seven (57) normative CCSDS standards may be fitted together, like some giant jig-saw puzzle, to mee the needs of users who design and build flight and ground communications assets. In the time
since that standard was published a number of these normative standards have been updated, some with new features, and a significant number of new standards have been published, especially in SLS and CSS, but also in SEA itself.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">We reviewed the major issues we identified with the current document structure that requires changes to the chapters for clarity of presentation. We also reviewed some of the complexities introduced by new standards,
such as USLP, optical comm, VCM, and newer security features that are driving a change in approach. And we discussed adding all of the new standards that have been introduced since this document was published.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">We are attaching the presentation where we discussed these issues and how we plan to address them. This is an unusual request for a WG, which typically do this sort of work behind closed doors, but since this
document cross cuts all of your WGs we thought it useful and, we hope, valuable to you. Since we have focused on ABA deployments the only Area that is not directly affected yet is SIS. SOIS, and others, also raised some issues having to do with relay architectures,
off-Earth instances of what are essentially treated as Earth-bound ESLT services in the ABA context. Most of this will be addressed in the “ABCBA” and Solar System Internet (SSI) configurations that are in the next batch of updates.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">I am attaching the presentation here. Please review it in the context of the current CCSDS 901.1-M-1 document, which these changes will update. In particular, for SSI and relay sorts of configurations, the SSI
sub-sections, even as they are now, should provide the necessary framework of functions, deployments, and examples to cover these future concerns.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">What follows is my scribbled notes from the WebEx. If there are any issues please provide corrections so that we have a “complete enough” of minutes with which to make progress in resolving issues.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Last comments: This is a complicated set of topics, with some distinct, if not clearly articulated, sets of relationships. In this document we wish to make these as clear as we can. In some cases we have identified
open issues that we, the CCSDS members, really ought to address. And in some cases we have new people, in new leadership positions, who will need help to understand the complexities and to help lead us to satisfactory, consensus-based, outcomes. My personal
request is that we try and work together, for the greater good, to develop and document outcomes that work for all of us and our user base.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Thanks, Peter<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> ===========================================================================================================================<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="color:black">Brief Meeting Notes – 23 June 2021</span></b><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Attendees: Shames, Krosley, De Cola, Pham, Vassallo, Sanchez-Aguillar, de Vicente, Hamkins, Volk, Haddow, Calzolari, Edwards, Kazz, Barkley, Wilmot, Schulz, Modenini (<u>please update if I left anyone off this
list</u>)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Discussion notes: relative to pages in the attached presentation<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Pgs 5-6, Andrews: What is the relationship of this CCSDS 901.1-M-1 SCCS-ARD doc to the existing SLS Overview of Space Communication Protocols (OSCP), CCSDS 130.0-G-3? Do we need both?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">Answer: The OSCP is a useful doc, and it covers the SLS (and some SIS) protocol stack, but the OSCP is not an architecture document and it does not address CSS at all, nor really much
about SIS. It may be a useful companion to the the SCCS-ARD, but it is much more limited in coverage of topics and only addresses a limited set the protocol stack and deployment issues. It is up to SLS to determine whether they wish to retain this document.<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"><span style="color:black">Pg 6, Calzolari: Raised the issue of the “Forward / Return File service, that it is a low IOAG priority (stated as “minus infinity”), and that agencies are doing as they wish to implement some sort of “split mode”
CFDP file delivery agent.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">Answer: Agreed that this is a low priority for CCSDS, and that it may be better for CCSDS to reject it, but that is not the role of this WG, we just make note of such problems. Agreed
that Agencies are free to implement “split mode CFDP” in any way they deem suitable, but that this is not a standard approach nor is it likely to be cross-supported.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Pgs 8-9: The group agreed that the use of the proposed revisions to Sec 4, and the new tables in Sec 6, made a lot of sense and were much clearer than the alternative.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Pg 11, Schulz: There was a later question as to whether this document is just listing possible options or making concrete recommendations about selections of future standards that are preferred.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">Answer: The inclusion of “R<n>” markings in various tables are, in fact, intended to draw attention to the CCSDS Recommended paths forward. We can, and should, revisit this as a group
and provide such guidance wherever we can. One stated example is recommending use of USLP for high rate, bi-directional, mission comms, such as for human rated missions, along with FF-CSTS.<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"><span style="color:black">Pg 12, Pham: The question was raised about inclusion of the EF-CLTU Orange Book in this document, particularly in Sec 4 Services, because it is of interest to the ISS and Artemis missions. This also came up again
in the context of Table 6-8, pg 17.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">Answer: There is agreement that we do need to address the use of this Experimental, Orange Book, spec for these important missions, but also agreement that we should not warp the already
complicated structure of this document to meet the needs of these slow moving missions that are retaining these older protocols. The recommendation is to put a new Note (N4) in table 6-8 (see pg 17) to the effect that while AOS forward links are recommended
to be supported by FF-CSTS, that they may be supported, in CLTU form, using F-CLTU or the obsolescent EF-CLTU. A similar note may be useful in Sec 4.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Pgs 12-20, Andrews: Ken raised a question about the meaning of the column headings in the tables on pgs 12-20. In many cases the column headers are observed to be the same as the protocol names on the rows. What
are these really intended to represent? Barkley wanted to make sure that “Interface Binding Signature” is clearly defined in the document.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">Answer: The column headers are really intended to name the Service/Function that is being provided. The rows are intended to map out the stack of protocols that support that service interface,
which is, in effect, the interface binding signature for the service. Recommendation is to reword the column headers to reflect their role as Service / Function (e.g “Deliver tracking data” instead of TD-CSTS) and the row entries as the protocols that form
the “stack”.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Pg 14, Haddow/Barkley: The question of just what was meant by “Raw Radiometric” data, or, for that matter, “Validated Radiometric” data was raised. This is in the context of using TGFT [64] and XFDU as the transport
method and data format.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">Answer: Agreed that the XFDU format, required content description, must be provided in order for the use of TGFT to make sense. Agreed that this is an issue that the MOIMS Nav WG is in
the best position to address.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">Typo? There was also a question about the “N” in the Raw Radiometric column of this table instead of an “M”?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Pg 14, de Vicente/Volk: The question of just how the D-DOR WG currently returns their voluminous file data, using the RDEF [38] formatted files was raised.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">Answer: The response shown, using SFTP, was stated to be accurate. We need a reference for this.<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"><span style="color:black">Pg 15, Haddow/Barkley: Why is HTTP over TLS [55] the protocol shown to carry SM “information entities”?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">Answer: This is intended to be future looking, and SM transport protocol is likely to be HTTP/REST therefore it is safe (enough) to use it in this table as a [Future] protocol. Agreed.<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"><span style="color:black">Pg 17, Sanchez-Aguilar, Pham, Schulz, and others: This table generated a lot of discussion. We traced AOS and TC, in particular, down through the stacks and into the notes. There was agreement that this was a
pretty good way to describe all of the complexities inherent in what has, in fact, been standardized. There was also a strong desire to understand just what we were trying to describe and to review these tables in detail. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Issues:<o:p></o:p></span></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoNormal" style="color:black;mso-list:l0 level1 lfo1">How does the TC path work?<o:p></o:p></li><li class="MsoNormal" style="color:black;mso-list:l0 level1 lfo1">How does the AOS path work?<o:p></o:p></li><li class="MsoNormal" style="color:black;mso-list:l0 level1 lfo1">How do the USLP (fixed and variable) path(s) work?<o:p></o:p></li><li class="MsoNormal" style="color:black;mso-list:l0 level1 lfo1">Why does F-CLTU for TC S&CC reference C2 which is only about optical comm?<o:p></o:p></li><li class="MsoNormal" style="color:black;mso-list:l0 level1 lfo1">Can we put a note, N4, into the cell for AOS forward and F-CLTU indicating that both F-CLTU, and EF-CLTU, can be used, with some local wrangling, to support synchronous AOS forward links, but
that FF-CSTS is recommended?<o:p></o:p></li><li class="MsoNormal" style="color:black;mso-list:l0 level1 lfo1">Just how much of what is in this table should be shown as “Recommended” as opposed to just “Optional”<o:p></o:p></li></ol>
<p class="MsoNormal" style="margin-left:.25in"><span style="color:black">Answer: Table still needs work and probably a new N4 note, at a minimum. <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.25in"><span style="color:black">Request: That this group undertake a careful review to make sure that these tables make sense and that they are accurate.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.25in"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Pg 17, Sanchez-Aguilar, Wilmot: How does this table address TC commands sent from a relay, or a relay S/C running DTN to a leaf node over a local / proximate protocol such as WiFi?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">Answer: All of these sorts of ABCBA and SSI deployment questions will be addressed in the SSI sub-sections of the document which will be worked in the next round of edits. The SSI sections
in the current edition should be reviewed with an eye toward whether this already provides a viable framework for such discussions. It defines a pretty broad variety of node types and possible / example configurations.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Pg 18, Schulz: What is the role of this document? Is it to provide recommendations or just documentation?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">Answer: There is the intent to provide recommendations of best options where we can reach consensus on what those might be. See discussion on pg 11. We will provide the current <b><i>draft</i></b> document,
and the “R<n>” parts to anyone who requests it.<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"><span style="color:black">Pg 21-24, Barkley: Is any simplification of the whole complex set of three almost identical VCM protocols going to be possible? It seems that Agency interests drove us to this awkward and complicated situation.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">Answer: While the SEA SAWG would also like to get this situation fixed we are in the same situation as we stated in Pg 6 (and 29-30) in regard Fwd/Ret CFDP. It is up to the CCSDS Areas
and WG to fix this stuff up. The best we can do is to point out that there are issues and to attempt to describe them as clearly as possible. We would like to encourage that this be done, the current situation is awkward, at best.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>