<span style=" font-size:10pt;font-family:sans-serif">Dear Jon,</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">thanks for informing
us about your correspondence with Peter.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">I think that your
views are in line with the discussions we had yesterday on a related topic
and for which the two groups attendees agreed on a different approach relative
to Pietra's RID.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Had we seen your
text before, we could have used it also as response to Pietra. Anyway,
it's good material for this never ending discussion.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Regards, Enrico</span>
<br>
<br>
<br>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">"Jon
Hamkins" <Jon.Hamkins@jpl.caltech.edu></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">Enrico.Vassallo@esa.int,
"Andrea Modenini (external)" <Andrea.Modenini@esa.int>,
"sls-rfm@mailman.ccsds.org" <sls-rfm@mailman.ccsds.org>,
"Space Link Coding & Synchronization Working Group" <sls-cc@mailman.ccsds.org></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style=" font-size:9pt;font-family:sans-serif">08/07/21
02:23</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">Re:
[Sls-rfm] Notes from today's SEA SAWG Coordination meeting on the SCCS-ARD
document updates</span>
<br>
<hr noshade>
<br>
<br>
<br><span style=" font-size:12pt">Enrico, Andrea,</span>
<br><span style=" font-size:12pt">In response to your request to provide
suggestions and copy the mailing list about the Space Communication Cross
Support Architecture Requirements Document, below I provide the feedback
I gave to Peter Shames immediately after the June 23 meeting on this topic.
Attached for convenience are the slides being commented upon.</span>
<br><span style=" font-size:12pt">***</span>
<br><span style=" font-size:12pt">Clearly a lot of effort has gone into
this. At some point I would like to go over the Section 6 tables and things
in more detail, and it may be some time before I will be able to do so.
But before things get too far down the track, I wanted to write to you
now regarding the treatment of VCM. This is meant in the spirit of constructive
criticism and leading to a better result for the SCCS-ARD. Here are some
detailed thoughts.</span>
<br><span style=" font-size:12pt">I confess that I don't see a convincing
case for including substantial VCM material in the SCCS-ARD. Unless a good
case can be made for why we need it, I suggest that we plan to leave it
out, except for describing the interface to the physical layer, which is
where the jig-saw pieces meet and description actually is missing from
the Blue Books. I think there are some good reasons why VCM in SCCS-ARD
is not needed:</span>
<ul>
<li><span style=" font-size:12pt">The current SCCS-ARD, published in 2015,
does not describe or refer to "VCM" anywhere, even though two
VCM-related Blue Books were years old by that point. I have not heard anyone
complain that more VCM description was needed than what was in the Blue
Books in order to understand how things fit together.</span>
<li><span style=" font-size:12pt">Since then, we have published a VCM Blue
Book that describes the unified protocol, with the differences between
the two Blue Books described as Type 1 and 2 variants. I believe the original
two books, together with the 431 book, make all of the necessary normative
statements needed about how VCM works.</span>
<li><span style=" font-size:12pt">The purpose of the SCCS-ARD is to describe
how the CCSDS standards fit together. That is already what 431 does, when
it comes to VCM. In fact, we had envisioned the 431 book as a Magenta book,
explaining how the common VCM protocol described in the SCCC and DVB-S2
standard could be used in conjunction with the TM codes.</span>
<li><span style=" font-size:12pt">There is no inter-operation between SCCC
and DVB-S2, making a diagram showing the details of them together on one
page unnecessary in the SCCS-ARD.</span>
<li><span style=" font-size:12pt">There is less need to describe VCM than
other standards in the SCCS-ARD, because there are fewer jig-saw puzzle
pieces to stitch together. The SCCC and DVB-S2 books are silos that are
self-contained with multiple layers included.</span></ul><span style=" font-size:12pt">I
also have comments about the slides themselves.</span>
<ul>
<li><span style=" font-size:12pt">"CCSDS has 3 VCM standards"
is poorly worded.</span>
<ul>
<li><span style=" font-size:12pt">We've always referred to SCCC and DVB-S2
as coding standards, together with some textbook modulations. And yes,
a VCM protocol. But I wouldn't call them "VCM standards." The
VCM was an ancillary, feather-in-the-cap feature of these new coding standards.
All of the debate about these standards was about the complexity, performance,
maturity, etc. of the codes.</span>
<li><span style=" font-size:12pt">In fact, the VCM protocol in the SCCC
and DVB-S2 books is nearly identical, with the same header in the same
place and of the same length using the same coding protection and same
pi/2 modulation. Also, the same architecture is used for pilot symbols,
for shaping, and near-identical modulation options. The 431 VCM book allows
use of the same VCM protocol with the TM codes. With one VCM protocol used
with many codes, I think it is a misleading to call that "3 VCM standards."</span></ul>
<li><span style=" font-size:12pt">I think the VCM figure makes things more
complicated and harder to understand than they actually are.</span>
<ul>
<li><span style=" font-size:12pt">My main issue is that the figure fails
to highlight that CCSDS has a unified VCM protocol which can be used in
conjunction with the three coding options SCCC, DVB-S2, and TM turbo/LDPC.
The figure makes it seem that everything about the signal flow is different
at every step in the three books.</span>
<li><span style=" font-size:12pt">A second main issue is that for a diagram
purportedly about VCM, there is little about how the VCM modes are signaled
in the header. Frame Descriptor and Physical Layer Signaling aren't even
mentioned, and those are the crux of the VCM architecture.</span>
<li><span style=" font-size:12pt">The term "VCM suite" is introduced.
This is a new term with no value or tie back to the Blue Books. It may
mislead the reader into thinking there are fundamentally different VCM
protocols, which I think is the opposite of what this figure should be
doing.</span>
<li><span style=" font-size:12pt">The "CCSDS VCM Protocol" is
shown as a block in the middle, when in reality as described in 431 it
encompasses both the SCCC and DVB-S2 protocols.</span>
<li><span style=" font-size:12pt">It is unclear from this diagram that
SCCC codes use Type 1 VCM and DVB-S2 use Type 2 VCM</span>
<li><span style=" font-size:12pt">The things that are common -- functions
like slicing, ASM, modulation, pilot -- are drawn multiple times, giving
the impression that they are different.</span>
<li><span style=" font-size:12pt">The slicer for DVB is shown within the
ETSI standard, when it is really part of the CCSDS standard (131.3).</span>
<li><span style=" font-size:12pt">The boxes labeled "variable coding
and modulation" contain no coding and no modulation. I think you mean
VCM control.</span>
<li><span style=" font-size:12pt">No VCM control is shown for the TM codes.</span>
<li><span style=" font-size:12pt">No VCM control is shown for the pilots.</span>
<li><span style=" font-size:12pt">No VCM control is shown for the slicer.</span>
<li><span style=" font-size:12pt">Arrows showing direction of flow are
missing throughout.</span>
<li><span style=" font-size:12pt">The circle-plus notation in the figure
is confusing. In other CCSDS standards, that notation means XOR, which
is not what is going on here.</span></ul>
<li><span style=" font-size:12pt">Regarding the all stacks diagram on p.
24</span>
<ul>
<li><span style=" font-size:12pt">One area I think the SCCS-ARD could help
with is making explicit that SCCC, DVB-S2, and TM coding books interface
to the RFM 401 book. P. 24 does a reasonable job of this, showing the RFM
below the SCCC and DVB-S2 codes and it should be backed up with words.</span>
<li><span style=" font-size:12pt">Again, p. 24 has a box called "VCM
suite," and all of SCCC and DVB-S2 and 431 are hidden inside that
box, which doesn't make sense. They are each their own blue book.</span>
<li><span style=" font-size:12pt">Please be aware that reasonable people
see different boundaries for the physical layer. The SCCC and DVB-S2 books
define the modulations, and the RFM book <i>also </i>defines the modulations.
Whether you choose to believe modulation is in the physical layer or the
coding sublayer is a matter of taste. In the optical standards, for example,
the physical layer is limited to physical quantities (frequencies, polarization,
linewidth, etc.), and modulation is considered to be in the coding sublayer.
That is because the modulation is part of the code. But the way p. 24 is
drawn implies an inconsistent interpretation what layer modulation is in.
You can't fix that, as the blue books have this inconsistency.</span></ul></ul><span style=" font-size:12pt">
----Jon</span>
<br><span style=" font-size:12pt"><b>Jon Hamkins</b><br>
Chief Technologist, Communications, Tracking, and Radar Division<br>
<b><br>
JPL</b> | jpl.nasa.gov </span>
<br><span style=" font-size:12pt">On 6/24/2021 2:05 AM, </span><a href=mailto:Enrico.Vassallo@esa.int><span style=" font-size:12pt;color:blue"><u>Enrico.Vassallo@esa.int</u></span></a><span style=" font-size:12pt">
wrote:</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Dear All,</span><span style=" font-size:12pt">
<br>
</span><span style=" font-size:10pt;font-family:sans-serif"><br>
please find the above mentioned attached presentation and some notes.</span><span style=" font-size:12pt">
<br>
</span><span style=" font-size:10pt;font-family:sans-serif"><br>
Feel free to ask any questions you may have or provide suggestions directly
to Peter while copying the whole RFM WG mailing list.</span><span style=" font-size:12pt">
<br>
</span><span style=" font-size:10pt;font-family:sans-serif"><br>
Enjoy the reading,</span><span style=" font-size:12pt"> <br>
</span><span style=" font-size:10pt;font-family:sans-serif"><br>
Enrico</span><span style=" font-size:12pt"> </span><span style=" font-size:9pt;color:#800080;font-family:sans-serif"><br>
----- Forwarded by Enrico Vassallo/esoc/ESA on 24/06/21 11:03 -----</span><span style=" font-size:12pt">
<br>
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif"><br>
From: </span><span style=" font-size:9pt;font-family:sans-serif">"Shames,
Peter M (US 312B)" </span><a href=mailto:peter.m.shames@jpl.nasa.gov><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><peter.m.shames@jpl.nasa.gov></u></span></a><span style=" font-size:12pt">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif"><br>
To: </span><span style=" font-size:9pt;font-family:sans-serif">"CCSDS
Engineering Steering Group - CESG Exec" </span><a href=mailto:cesg@mailman.ccsds.org><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><cesg@mailman.ccsds.org></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
</span><a href=mailto:Enrico.Vassallo@esa.int><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u>"Enrico.Vassallo@esa.int"</u></span></a><span style=" font-size:9pt;font-family:sans-serif">
</span><a href=mailto:Enrico.Vassallo@esa.int><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><Enrico.Vassallo@esa.int></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
"D'Amore Giuseppe" </span><a href=mailto:giuseppe.damore@asi.it><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><giuseppe.damore@asi.it></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
"Gilles Moury" </span><a href=mailto:Gilles.Moury@cnes.fr><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><Gilles.Moury@cnes.fr></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
"Colin Haddow" </span><a href=mailto:Colin.Haddow@esa.int><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><Colin.Haddow@esa.int></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
</span><a href=mailto:Andrea.Modenini@esa.int><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u>"Andrea.Modenini@esa.int"</u></span></a><span style=" font-size:9pt;font-family:sans-serif">
</span><a href=mailto:Andrea.Modenini@esa.int><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><Andrea.Modenini@esa.int></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
"Lee, Dennis K (US 332G)" </span><a href=mailto:dennis.k.lee@jpl.nasa.gov><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><dennis.k.lee@jpl.nasa.gov></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
</span><a href=mailto:Ignacio.Aguilar.Sanchez@esa.int><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u>"Ignacio.Aguilar.Sanchez@esa.int"</u></span></a><span style=" font-size:9pt;font-family:sans-serif">
</span><a href=mailto:Ignacio.Aguilar.Sanchez@esa.int><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><Ignacio.Aguilar.Sanchez@esa.int></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
"EXTERNAL-Pietras, John V (US 332C-Affiliate)" </span><a href=mailto:john.pietras@gst.com><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><john.pietras@gst.com></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
"Andrews, Kenneth S (US 332B)" </span><a href=mailto:kenneth.s.andrews@jpl.nasa.gov><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><kenneth.s.andrews@jpl.nasa.gov></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
"Barkley, Erik J (US 3970)" </span><a href=mailto:erik.j.barkley@jpl.nasa.gov><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><erik.j.barkley@jpl.nasa.gov></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
"Hamkins, Jon (US 3300)" </span><a href=mailto:jon.hamkins@jpl.nasa.gov><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><jon.hamkins@jpl.nasa.gov></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
"Pham, Timothy T (US 3300)" </span><a href=mailto:timothy.t.pham@jpl.nasa.gov><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><timothy.t.pham@jpl.nasa.gov></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
"Bernie Edwards" </span><a href=mailto:bernard.l.edwards@nasa.gov><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><bernard.l.edwards@nasa.gov></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
"Volk, Christopher P (US 335D)" </span><a href=mailto:christopher.p.volk@jpl.nasa.gov><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><christopher.p.volk@jpl.nasa.gov></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
"Ramon Krosley" </span><a href=mailto:r.krosley@andropogon.org><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><r.krosley@andropogon.org></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
"Kazz, Greg J (US 312B)" </span><a href=mailto:greg.j.kazz@jpl.nasa.gov><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><greg.j.kazz@jpl.nasa.gov></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
</span><a href=mailto:Ricard.Abello@esa.int><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u>"Ricard.Abello@esa.int"</u></span></a><span style=" font-size:9pt;font-family:sans-serif">
</span><a href=mailto:Ricard.Abello@esa.int><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><Ricard.Abello@esa.int></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
</span><a href=mailto:Javier.DeVicente@esa.int><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u>"Javier.DeVicente@esa.int"</u></span></a><span style=" font-size:9pt;font-family:sans-serif">
</span><a href=mailto:Javier.DeVicente@esa.int><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><Javier.DeVicente@esa.int></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
"Howie Weiss" </span><a href=mailto:Howard.Weiss@parsons.com><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><Howard.Weiss@parsons.com></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
"Keith Scott" </span><a href=mailto:kscott@mitre.org><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><kscott@mitre.org></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
</span><a href=mailto:Mario.Merri@esa.int><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u>"Mario.Merri@esa.int"</u></span></a><span style=" font-size:9pt;font-family:sans-serif">
</span><a href=mailto:Mario.Merri@esa.int><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><Mario.Merri@esa.int></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
"he xiongwen" </span><a href=mailto:hexw501@hotmail.com><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><hexw501@hotmail.com></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
</span><a href=mailto:Gian.Paolo.Calzolari@esa.int><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u>"Gian.Paolo.Calzolari@esa.int"</u></span></a><span style=" font-size:9pt;font-family:sans-serif">
</span><a href=mailto:Gian.Paolo.Calzolari@esa.int><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><Gian.Paolo.Calzolari@esa.int></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
"Lotten Bergstroem (external)" </span><a href=mailto:Lotten.Bergstroem@esa.int><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><Lotten.Bergstroem@esa.int></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
"Wilmot, Jonathan J. (GSFC-5800)" </span><a href=mailto:jonathan.j.wilmot@nasa.gov><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><jonathan.j.wilmot@nasa.gov></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
"Klaus-Juergen Schulz" </span><a href="mailto:Klaus-Juergen.Schulz@esa.int"><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><Klaus-Juergen.Schulz@esa.int></u></span></a><span style=" font-size:9pt;font-family:sans-serif">,
</span><a href=mailto:Enrico.Vassallo@esa.int><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u>"Enrico.Vassallo@esa.int"</u></span></a><span style=" font-size:9pt;font-family:sans-serif">
</span><a href=mailto:Enrico.Vassallo@esa.int><span style=" font-size:9pt;color:blue;font-family:sans-serif"><u><Enrico.Vassallo@esa.int></u></span></a><span style=" font-size:12pt">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif"><br>
Date: </span><span style=" font-size:9pt;font-family:sans-serif">24/06/21
00:53</span><span style=" font-size:12pt"> </span><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif"><br>
Subject: </span><span style=" font-size:9pt;font-family:sans-serif">Notes
from today's SEA SAWG Coordination meeting on the SCCS-ARD document updates</span><span style=" font-size:12pt">
<br>
</span>
<hr noshade><span style=" font-size:12pt"><br>
</span>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Dear
SLS, CSS, SIS, SEA, and SOIS colleagues,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Thanks,
Peter</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"><b>Brief
Meeting Notes – 23 June 2021</b></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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>)</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Discussion
notes: relative to pages in the attached presentation</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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”.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Typo?
There was also a question about the “N” in the Raw Radiometric
column of this table instead of an “M”?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Answer:
The response shown, using SFTP, was stated to be accurate. We need
a reference for this.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Pg
15, Haddow/Barkley: Why is HTTP over TLS [55] the protocol shown to carry
SM “information entities”?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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. </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Issues:</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">1.
</span><span style=" font-size:11pt;font-family:Calibri">How
does the TC path work?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">2.
</span><span style=" font-size:11pt;font-family:Calibri">How
does the AOS path work?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">3.
</span><span style=" font-size:11pt;font-family:Calibri">How
do the USLP (fixed and variable) path(s) work?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">4.
</span><span style=" font-size:11pt;font-family:Calibri">Why
does F-CLTU for TC S&CC reference C2 which is only about optical comm?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">5.
</span><span style=" font-size:11pt;font-family:Calibri">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?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">6.
</span><span style=" font-size:11pt;font-family:Calibri">Just
how much of what is in this table should be shown as “Recommended” as
opposed to just “Optional”</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Answer:
Table still needs work and probably a new N4 note, at a minimum. </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Request:
That this group undertake a careful review to make sure that these tables
make sense and that they are accurate.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Pg
18, Schulz: What is the role of this document? Is it to provide recommendations
or just documentation?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<br><tt><span style=" font-size:12pt">This message is intended only for
the recipient(s) named above. It may contain proprietary information and/or<br>
protected content. Any unauthorised disclosure, use, retention or dissemination
is prohibited. If you have received<br>
this e-mail in error, please notify the sender immediately. ESA applies
appropriate organisational measures to protect<br>
personal data, in case of data privacy queries, please contact the ESA
Data Protection Officer (</span></tt><a href=mailto:dpo@esa.int><tt><span style=" font-size:12pt;color:blue"><u>dpo@esa.int</u></span></tt></a><tt><span style=" font-size:12pt">).<br>
</span></tt>
<br>
<br><tt><span style=" font-size:12pt">_______________________________________________<br>
SLS-RFM mailing list<br>
</span></tt><a href="mailto:SLS-RFM@mailman.ccsds.org"><tt><span style=" font-size:12pt;color:blue"><u>SLS-RFM@mailman.ccsds.org</u></span></tt></a><tt><span style=" font-size:12pt"><br>
</span></tt><a href="https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-rfm__;!!PvBDto6Hs4WbVuu7!drNJuVdVuDeS8T4RT9_swProBOul7HtBi6LFjDkS-whoICkr160iOWcJNKgrhzlrAq7EnLrh$"><tt><span style=" font-size:12pt;color:blue"><u>https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-rfm__;!!PvBDto6Hs4WbVuu7!drNJuVdVuDeS8T4RT9_swProBOul7HtBi6LFjDkS-whoICkr160iOWcJNKgrhzlrAq7EnLrh$</u></span></tt></a><tt><span style=" font-size:12pt">
<br>
[attachment "SCCS-ARD_5yr_refresh-210623.pptx" deleted by Enrico
Vassallo/esoc/ESA] </span></tt>
<br>
<br>
<PRE>This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@esa.int).
</PRE>