<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Enrico, Andrea,</p>
<p>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.<br>
</p>
<p>***<br>
</p>
<p>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.<br>
</p>
<p>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:<br>
</p>
<ul>
<li>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.<br>
</li>
<li>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.<br>
</li>
<li>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.</li>
<li>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.<br>
</li>
<li>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.</li>
</ul>
<p>I also have comments about the slides themselves.<br>
</p>
<ul>
<li>"CCSDS has 3 VCM standards" is poorly worded.</li>
<ul>
<li>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.</li>
<li>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."<br>
</li>
</ul>
<li>I think the VCM figure makes things more complicated and
harder to understand than they actually are.</li>
<ul>
<li>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.</li>
<li>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.<br>
</li>
<li>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.<br>
</li>
<li>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.<br>
</li>
<li>It is unclear from this diagram that SCCC codes use Type 1
VCM and DVB-S2 use Type 2 VCM</li>
<li>The things that are common -- functions like slicing, ASM,
modulation, pilot -- are drawn multiple times, giving the
impression that they are different.</li>
<li>The slicer for DVB is shown within the ETSI standard, when
it is really part of the CCSDS standard (131.3).</li>
<li>The boxes labeled "variable coding and modulation" contain
no coding and no modulation. I think you mean VCM control.<br>
</li>
<li>No VCM control is shown for the TM codes.</li>
<li>No VCM control is shown for the pilots.</li>
<li>No VCM control is shown for the slicer.<br>
</li>
<li>Arrows showing direction of flow are missing throughout.<br>
</li>
<li>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.</li>
</ul>
<li>Regarding the all stacks diagram on p. 24</li>
<ul>
<li>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.</li>
<li>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.<br>
</li>
<li>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.<br>
</li>
</ul>
</ul>
<p> ----Jon</p>
<div class="moz-signature"><strong>Jon Hamkins</strong><br>
Chief Technologist, Communications, Tracking, and Radar Division<br>
<br>
<strong>JPL</strong> | jpl.nasa.gov
</div>
<div class="moz-cite-prefix">On 6/24/2021 2:05 AM,
<a class="moz-txt-link-abbreviated" href="mailto:Enrico.Vassallo@esa.int">Enrico.Vassallo@esa.int</a> wrote:<br>
</div>
<blockquote type="cite"
cite="mid:62145_1624525544_60D44AE7_62145_214_1_OF50A7F846.986AC368-ONC12586FE.0031C21B-C12586FE.0031F50F@esa.int">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<span style=" font-size:10pt;font-family:sans-serif">Dear All,</span>
<br>
<br>
<span style=" font-size:10pt;font-family:sans-serif">please find
the
above mentioned attached presentation and some notes.</span>
<br>
<br>
<span style=" font-size:10pt;font-family:sans-serif">Feel free to
ask
any questions you may have or provide suggestions directly to
Peter while
copying the whole RFM WG mailing list.</span>
<br>
<br>
<span style=" font-size:10pt;font-family:sans-serif">Enjoy the
reading,</span>
<br>
<br>
<span style=" font-size:10pt;font-family:sans-serif">Enrico</span>
<br>
<span style=" font-size:9pt;color:#800080;font-family:sans-serif">-----
Forwarded by Enrico Vassallo/esoc/ESA on 24/06/21 11:03 -----</span>
<br>
<br>
<span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style="
font-size:9pt;font-family:sans-serif">"Shames,
Peter M (US 312B)" <a class="moz-txt-link-rfc2396E" href="mailto:peter.m.shames@jpl.nasa.gov"><peter.m.shames@jpl.nasa.gov></a></span>
<br>
<span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style="
font-size:9pt;font-family:sans-serif">"CCSDS
Engineering Steering Group - CESG Exec"
<a class="moz-txt-link-rfc2396E" href="mailto:cesg@mailman.ccsds.org"><cesg@mailman.ccsds.org></a>,
<a class="moz-txt-link-rfc2396E" href="mailto:Enrico.Vassallo@esa.int">"Enrico.Vassallo@esa.int"</a> <a class="moz-txt-link-rfc2396E" href="mailto:Enrico.Vassallo@esa.int"><Enrico.Vassallo@esa.int></a>,
"D'Amore
Giuseppe" <a class="moz-txt-link-rfc2396E" href="mailto:giuseppe.damore@asi.it"><giuseppe.damore@asi.it></a>, "Gilles Moury"
<a class="moz-txt-link-rfc2396E" href="mailto:Gilles.Moury@cnes.fr"><Gilles.Moury@cnes.fr></a>, "Colin Haddow"
<a class="moz-txt-link-rfc2396E" href="mailto:Colin.Haddow@esa.int"><Colin.Haddow@esa.int></a>,
<a class="moz-txt-link-rfc2396E" href="mailto:Andrea.Modenini@esa.int">"Andrea.Modenini@esa.int"</a> <a class="moz-txt-link-rfc2396E" href="mailto:Andrea.Modenini@esa.int"><Andrea.Modenini@esa.int></a>, "Lee,
Dennis K (US 332G)" <a class="moz-txt-link-rfc2396E" href="mailto:dennis.k.lee@jpl.nasa.gov"><dennis.k.lee@jpl.nasa.gov></a>,
<a class="moz-txt-link-rfc2396E" href="mailto:Ignacio.Aguilar.Sanchez@esa.int">"Ignacio.Aguilar.Sanchez@esa.int"</a>
<a class="moz-txt-link-rfc2396E" href="mailto:Ignacio.Aguilar.Sanchez@esa.int"><Ignacio.Aguilar.Sanchez@esa.int></a>, "EXTERNAL-Pietras, John
V
(US 332C-Affiliate)" <a class="moz-txt-link-rfc2396E" href="mailto:john.pietras@gst.com"><john.pietras@gst.com></a>, "Andrews,
Kenneth S (US 332B)" <a class="moz-txt-link-rfc2396E" href="mailto:kenneth.s.andrews@jpl.nasa.gov"><kenneth.s.andrews@jpl.nasa.gov></a>,
"Barkley,
Erik J (US 3970)" <a class="moz-txt-link-rfc2396E" href="mailto:erik.j.barkley@jpl.nasa.gov"><erik.j.barkley@jpl.nasa.gov></a>, "Hamkins,
Jon (US 3300)" <a class="moz-txt-link-rfc2396E" href="mailto:jon.hamkins@jpl.nasa.gov"><jon.hamkins@jpl.nasa.gov></a>, "Pham, Timothy
T (US 3300)" <a class="moz-txt-link-rfc2396E" href="mailto:timothy.t.pham@jpl.nasa.gov"><timothy.t.pham@jpl.nasa.gov></a>, "Bernie
Edwards"
<a class="moz-txt-link-rfc2396E" href="mailto:bernard.l.edwards@nasa.gov"><bernard.l.edwards@nasa.gov></a>, "Volk, Christopher P (US
335D)"
<a class="moz-txt-link-rfc2396E" href="mailto:christopher.p.volk@jpl.nasa.gov"><christopher.p.volk@jpl.nasa.gov></a>, "Ramon Krosley"
<a class="moz-txt-link-rfc2396E" href="mailto:r.krosley@andropogon.org"><r.krosley@andropogon.org></a>,
"Kazz, Greg J (US 312B)" <a class="moz-txt-link-rfc2396E" href="mailto:greg.j.kazz@jpl.nasa.gov"><greg.j.kazz@jpl.nasa.gov></a>,
<a class="moz-txt-link-rfc2396E" href="mailto:Ricard.Abello@esa.int">"Ricard.Abello@esa.int"</a>
<a class="moz-txt-link-rfc2396E" href="mailto:Ricard.Abello@esa.int"><Ricard.Abello@esa.int></a>, <a class="moz-txt-link-rfc2396E" href="mailto:Javier.DeVicente@esa.int">"Javier.DeVicente@esa.int"</a>
<a class="moz-txt-link-rfc2396E" href="mailto:Javier.DeVicente@esa.int"><Javier.DeVicente@esa.int></a>,
"Howie Weiss" <a class="moz-txt-link-rfc2396E" href="mailto:Howard.Weiss@parsons.com"><Howard.Weiss@parsons.com></a>, "Keith Scott"
<a class="moz-txt-link-rfc2396E" href="mailto:kscott@mitre.org"><kscott@mitre.org></a>, <a class="moz-txt-link-rfc2396E" href="mailto:Mario.Merri@esa.int">"Mario.Merri@esa.int"</a>
<a class="moz-txt-link-rfc2396E" href="mailto:Mario.Merri@esa.int"><Mario.Merri@esa.int></a>,
"he xiongwen" <a class="moz-txt-link-rfc2396E" href="mailto:hexw501@hotmail.com"><hexw501@hotmail.com></a>,
<a class="moz-txt-link-rfc2396E" href="mailto:Gian.Paolo.Calzolari@esa.int">"Gian.Paolo.Calzolari@esa.int"</a>
<a class="moz-txt-link-rfc2396E" href="mailto:Gian.Paolo.Calzolari@esa.int"><Gian.Paolo.Calzolari@esa.int></a>, "Lotten Bergstroem
(external)"
<a class="moz-txt-link-rfc2396E" href="mailto:Lotten.Bergstroem@esa.int"><Lotten.Bergstroem@esa.int></a>, "Wilmot, Jonathan J.
(GSFC-5800)"
<a class="moz-txt-link-rfc2396E" href="mailto:jonathan.j.wilmot@nasa.gov"><jonathan.j.wilmot@nasa.gov></a>, "Klaus-Juergen Schulz"
<a class="moz-txt-link-rfc2396E" href="mailto:Klaus-Juergen.Schulz@esa.int"><Klaus-Juergen.Schulz@esa.int></a>,
<a class="moz-txt-link-rfc2396E" href="mailto:Enrico.Vassallo@esa.int">"Enrico.Vassallo@esa.int"</a> <a class="moz-txt-link-rfc2396E" href="mailto:Enrico.Vassallo@esa.int"><Enrico.Vassallo@esa.int></a></span>
<br>
<span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style="
font-size:9pt;font-family:sans-serif">24/06/21
00:53</span>
<br>
<span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">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>
<br>
<hr noshade="noshade">
<br>
<br>
<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>
<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 (<a class="moz-txt-link-abbreviated" href="mailto:dpo@esa.int">dpo@esa.int</a>).
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
SLS-RFM mailing list
<a class="moz-txt-link-abbreviated" href="mailto:SLS-RFM@mailman.ccsds.org">SLS-RFM@mailman.ccsds.org</a>
<a class="moz-txt-link-freetext" href="https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-rfm__;!!PvBDto6Hs4WbVuu7!drNJuVdVuDeS8T4RT9_swProBOul7HtBi6LFjDkS-whoICkr160iOWcJNKgrhzlrAq7EnLrh$">https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-rfm__;!!PvBDto6Hs4WbVuu7!drNJuVdVuDeS8T4RT9_swProBOul7HtBi6LFjDkS-whoICkr160iOWcJNKgrhzlrAq7EnLrh$</a>
</pre>
</blockquote>
</body>
</html>