[SLS-CC] [EXTERNAL] Re: Fw: WebEx meeting invitation: SCCS-ARD update review scheduled for Tuesday, 23 Nov, 2021 at 0700 AM PST

Jon Hamkins Jon.Hamkins at jpl.nasa.gov
Tue Nov 30 03:29:52 UTC 2021


Thanks, Peter. I think we will make faster progress with a webex meeting 
rather than email. I would like to resolve each of the six comments.

      ----Jon

*Jon Hamkins*
Chief Technologist, Communications, Tracking, and Radar Division
*O* 818-354-4764   | *M* 626-658-6220

*JPL*   |   jpl.nasa.gov
On 11/29/2021 3:29 PM, Shames, Peter M (US 312B) wrote:
>
> Hi Jon and all our other SLS C&S and RFM WG colleagues.
>
> In the context of the Space Communication Cross Support (SCCS) 
> Architecture Requirements Document (ARD) we have this on-going 
> discussion of the state of the SLS “VCM Suite” of variable coding and 
> modulation standards.  Jon has pointed out, at length, that there is 
> no term “VCM suite” defined within the C&S WG or within any of the SLS 
> Area literature.  I have to agree that this statement, taken by 
> itself, is true.
>
> What Jon has then requested is that this term “VCM Suite”, and the 
> diagram we have constructed to explain the complexities of this 
> situation, be replaced in the SCCS-ARD by the single term “the VCM 
> protocol” and also be shown as three separate boxes in figure 6-1, 
> Layering of CCSDS link layer protocols.
>
> Last week we held a 2 hour review of all of the major changes we have 
> introduced in the SCCS-ARD.  These changes are due to the usual 5 year 
> document review and the addition of many new standards, several of 
> which had only been forecast in the original edition.  Among these 
> were the DVB-S2 (CCSDS 131.1-B-2), the SCCC (CCSDS 131.2-B-2), and the 
> VCM (CCSDS 431.1-B-1).  What cannot be in question is that all three 
> of these describe themselves as “VCM protocols”.  Even the 431.1 
> document describes all three of these, separately, as VCM protocols.
>
> See the two attachments for screen shots of the 431.1 document where 
> these statements are made and where some of the differences are 
> described, in text.
>
> The 431.1-B-1 document also makes this statement, in Sec 1.2  Purpose 
> and Scope
>
> The purpose of this Recommended Standard is to specify various 
> combinations of coding and modulations in references [1], [2], [4], 
> and [5], that can operate under the VCM protocol defined in references 
> [2] and [4]. This enables, for example, some of the CCSDS recommended 
> channel codes (reference [1]) and modulations (reference [5]) to be 
> used with the CCSDS VCM protocol.
>
> In reading through this 431.1-B-1 document, again, I am struck fact 
> that the document, in two different sentences, says “there are three 
> different VCM protocols”, and then “there is one ‘CCSDS VCM 
> protocol’”.  Just looking again at these documents, all three of them, 
> three things are very clear:
>
>  1. There are three separate documents, each of which is defined as a
>     “VCM protocol”.
>  2. The three are similar, but, in detailed fact, are different and
>     cannot interoperate.
>  3. The third of these, CCSDS 431.1 cannot stand alone, it is
>     meaningless without heavy reliance on major parts of DVB-S2 and
>     SCCC, which it terms as Type 1 and Type 2 VCM schemes.
>
> I am not going to un-Earth the history of how we got into this 
> situation, but I firmly believe that if we asked any knowledgeable, 
> independent, reviewer with relevant technical background to review 
> these three standards they would ask “Why do you have three nearly 
> identical standards when one would do?”.
>
> But the facts are that we do have two nearly identical standards and a 
> third one that could not exist at all without the other two, which it 
> is (almost) entirely dependent upon.  This is unique in CCSDS.
>
> As for SCCS-ARD, the attached PPT file will make clear how we propose 
> to handle this situation.  Instead of showing the Telemetry S&C, and 
> the Telecommand S&C, and three separate, different, but admittedly 
> nearly identical, VCM protocols, we have chosen to call this set of 
> triplets the “VCM suite”, to show how these fit with the other related 
> standards, and to show their similarities and differences.  We think 
> that this both provides visibility to this VCM technique, allows us to 
> state what value they bring (primarily for high rate downlink 
> missions), and also to not overly complicate an already complicated 
> diagram with three essentially identical VCM protocols.
>
> We called this trio of VCM standards the “VCM suite”.  If you all have 
> a better name to suggest we are open to hearing it.  All of the other 
> people we have had review this agree that this is a suitably simple, 
> and effective, way to deal with this complicated situation.
>
> If we need to have a WebEx to discuss this I am more than willing to 
> set one up.
>
> Thanks, Peter
>
> *From: *SLS-CC <sls-cc-bounces at mailman.ccsds.org> on behalf of Jon 
> Hamkins via SLS-CC <sls-cc at mailman.ccsds.org>
> *Reply-To: *Jon Hamkins <jon.hamkins at jpl.nasa.gov>
> *Date: *Sunday, November 14, 2021 at 11:05 PM
> *To: *Space Link Coding & Synchronization Working Group 
> <sls-cc at mailman.ccsds.org>, "sls-rfm at mailman.ccsds.org" 
> <sls-rfm at mailman.ccsds.org>, CCSDS Engineering Steering Group - CESG 
> All <cesg-all at mailman.ccsds.org>
> *Subject: *[EXTERNAL] Re: [SLS-CC] Fw: WebEx meeting invitation: 
> SCCS-ARD update review scheduled for Tuesday, 23 Nov, 2021 at 0700 AM PST
>
> Thank you for the invitation to review the SCCS-ARD. I regret that I 
> will not be able to discuss the SCCS-ARD in person on 23 Nov. I will 
> be on vacation that week. I give my comments here, with the hope that 
> this is enough in advance of the meeting for each of the individual 
> comments to be read and discussed at the meeting.
>
> My primary comment is that updating the SCCS-ARD is clearly a large 
> undertaking, and I would like to congratulate John Pietras and Peter 
> Shames for on the production of a quality document. It is difficult to 
> absorb such a large swath of CCSDS standards and integrate them into a 
> helpful summary of the interfaces as this SCCS-ARD does.
>
> My other comments primarily relate to the new VCM content. There are 
> six main comments, with more detailed description, recommendation, and 
> justification for each. These comments are written based on the latest 
> SCCS-ARD, but I also repeat portions of my June-23 comments if they 
> were not yet addressed. I believe the SCCS-ARD will be much improved 
> if we adopt these recommendations.
>
>   * The phrase "VCM suite"
>       o Description: This phrase is introduced in this SCCS-ARD. It
>         occurs in Table 6-1, and throughout Section 6.1.2, Table 6-8,
>         Table 6-12.
>       o Recommendation: Remove this phrase in all places and replace
>         with "the VCM protocol."
>       o Justification
>           + CCSDS does not have a "VCM suite" and I think it is a
>             mistake to invent this new concept here, especially since
>             it would risk confusing the reader into thinking that
>             there is more than one VCM protocol.
>           + 131.2 and 131.3 are not members of a supposed "VCM suite."
>             They are not even the same kind of thing that 431.1 is.
>             431.1 is a protocol book, while 131.2 and 131.3 describes
>             codes, modulation, and VCM.
>           + One VCM protocol. As we worked out in the C&S and RFM WGs
>             at the time we negotiated the VCM protocol blue book
>             (431.1-B-1), there is one VCM protocol that can be used
>             with multiple sets of codes and modulations described in
>             other blue books. There are some variations and options in
>             this protocol, but it is fundamentally one protocol that
>             operates in the same way, namely, with a header signaled
>             with pi/2-BPSK and protected with a specific RM code,
>             followed by code symbols using a higher order modulation.
>             This is why the VCM blue book has the title "Variable
>             Coded Modulation Protocol" with no plural word or "suite."
>           + In other words, the protocol is singular. What is plural
>             is the set of VCM tables that can be used in conjunction
>             with the protocol. Incidentally, in other areas CCSDS
>             doesn't refer to a "code suite," or a "ranging suite" or a
>             "frequencies suite" where there are clearly multiple options.
>   * Table 6-1 organization.
>       o Description: Table 6-1 lists three references for the VCM
>         "Suite": 131.2, 131.3, and 431.1.
>       o Recommendation: put 131.2, 131.3, and 431.1 each on their own
>         row of the table, using their Blue Book name, like the other
>         rows of the table do.
>       o Justification
>           + Books that are the same type of thing are treated
>             differently in the table.
>               # As we know, there are 4 CCSDS coding standards that
>                 ingest TM/AOS/USLP frames (what we might previously
>                 call space-to-ground links): 131.0 (turbo/LDPC), 131.2
>                 (SCCC), 131.3 (DVB-S2 LDPC), and 142.1 (SCPPM). These
>                 references should appear together in Table 6-1 in the
>                 same way, not with 131.0 in its own row and 131.2 and
>                 131.3 relegated to a secondary category within "VCM
>                 suite." The SCCS-ARD should be about interfaces (in
>                 this case, ingestion of TM, AOS, or USLP Transfer
>                 Frames). Treating them differently in the table
>                 doesn't make sense.
>               # In particular, Table 6-1 as written calls out 142.1
>                 and 131.0 as "coding" books and 131.2 and 131.3 as
>                 members of a supposed "VCM suite." But 131.2 and 131.3
>                 are primarily about the codes they define -- the SCCC
>                 codes and DVB-S2 LDPC codes. When C&S negotiated their
>                 acceptance, the discussion was primarily about the
>                 coding performance, complexity, maturity, etc., and
>                 not their associated VCM approaches (which are nearly
>                 identical).
>           + Books that are different are treated as though they are
>             the same in the table
>               # 131.2, 131.3, and 431.1 cannot be listed as though
>                 they are the same type of thing
>               # 431.1 is fundamentally different in structure from
>                 131.2 and 131.3. 431.1 is the unifying description of
>                 the (one) CCSDS VCM protocol, and refers back to 131.2
>                 and 131.3 in describing the differences of the two
>                 minor variations (types). Whereas 131.2 and 131.3
>                 describe codes and modulations.
>           + This would be consistent with the rest of the table.
>   * Table 6-1 "space-to-ground links".
>       o Description: The table has a left-column heading labeled
>         "Space-to-Ground Links."
>       o Recommendation:
>           + Remove or reword "Space-to-Ground Links"
>       o Justification:
>           + This may be outdated terminology, given our renewed
>             interest in allowing a variety of link directions for the
>             standards.
>           + Or, if we are keeping the concept of direction, why is the
>             TC coding book listed in this category? Also, why is there
>             no corresponding "Ground-to-Space Links" category?
>   * Figure 6-1
>       o Description: Figure 6-1 shows boxes for TM sync and channel
>         coding, VCM suite, and RF and modulation, with some lines
>         between some of them.
>       o Recommendation: Revise the figure to include an "SCCC coding"
>         box, a "DVB-S2 LDPC coding" (or similar) box, and redraw the
>         VCM box to encompass those boxes as well as the "TM sync and
>         channel coding" and "RF and Modulation" boxes. Also, update
>         the lines to make clear which frame types may enter each of
>         the boxes on the coding sublayer.
>       o Justification: As drawn, this figure is not clear and
>         bordering on inaccurate.
>           + There is a box labeled VCM suite, presumably meant to
>             include 131.2, 131.3, and 431.1 in this box. If so, then
>             why is TM Sync And Channel Coding outside of this box? Why
>             is RF and Modulation outside of this box? Those are
>             specified as part of 431.1.
>           + It does not make sense for turbo/LDPC codes to get their
>             own box in this figure, but not SCCC and DVB-S2 codes.
>             These make the same type of specification at the same
>             layer. Where SCCS-ARD can be of service is in explaining
>             where the interfaces are the same in the various books.
>           + VCM is a standard about both coding and modulation and so
>             should be drawn to encompass the coding and modulation
>             functions.
>   * Section 6.1.2.2.1
>       o Description. This section:
>           + States that the VCM suite is not a single protocol but
>             rather three separate protocols, then says they are "very
>             similar," and finally then says they are all subsumed into
>             one, using the phrase "the VCM protocol."
>           + Refers to 131.2 and 131.3 as "VCM standards"
>           + Says that 431.1 subsumes the functionality of 131.2 and 131.3
>       o Recommendation: Rewrite the paragraph from scratch to include
>         these features
>           + Refer to 131.0, 131.2, and 131.3 on equal footing as
>             standards for turbo/LDPC, SCCC, and DVB-S2 LDPC codes, and
>             a variety of modulations.
>           + Refer to 431.1 ("the VCM protocol") as allowing the codes
>             specified in these three standards to be used with a
>             common protocol with two variations called Type 1 and Type
>             2; and that the VCM protocol is easily updated to
>             accommodate other codes and/or modulations with the
>             additional of new VCM tables.
>       o Justification:
>           + As written, the paragraph is self-contradictory. The
>             protocol cannot simultaneously be three separate things,
>             two very similar things, and all subsumed into one thing.
>           + The simplicity of the concept of unifying VCM into a
>             common protocol that can be used with SCCC, DVB-S2 and
>             turbo/LDPC codes is missing from this paragraph.
>           + Saying 431.1 "subsumes" 131.2 and 131.3 makes it seem like
>             131.2 and 131.3 are not needed. They are needed, because
>             they are what specifies the codes and modulations. 431.1
>             /refers/ to 131.2 and 131.3.
>   * Figure 6-2
>       o Description. The figure purports to show component standards
>         of "the VCM suite."
>       o Recommendation:
>           + Remove this figure from the SCCS-ARD.
>       o Justification. This figure is unnecessary, redundant,
>         artificially complex, misleading, and incomplete.
>           + Unnecessary
>               # There is no "VCM suite."
>               # The purpose of the SCCS-ARD is to explain how things
>                 fit together. But this figure purportedly shows three
>                 standards -- 131.2, 431.1, and 131.3 -- /that do not
>                 interact with each other/ (there are no lines between
>                 the three main boxes)/. /This makes it unnecessary for
>                 the SCCS-ARD to address.
>           + Redundant, artificially complex
>               # No information would be lost if the 131.2 and 131.3
>                 columns were deleted in their entirety. All of the
>                 SCCC encoding is shown within the middle (431) box,
>                 for example. This duplication is confusing and
>                 artificially adds complexity where there is none.
>               # The things that are common -- functions like slicing,
>                 ASM, modulation, pilot -- are drawn multiple times,
>                 giving the impression that they are different.
>               # There is so much stuff on this figure that it has been
>                 shrunk so that the font is 6 pts. This is not legible
>                 without zooming.
>           + Misleading
>               # The duplication mentioned above may confuse a reader
>                 into believing that there is more than one VCM
>                 protocol that applies to SCCC codes (similarly, for
>                 DVB-S2 codes). This is the opposite of what this
>                 figure should be doing.
>               # The slicer for DVB is shown within the ETSI standard,
>                 when it is really part of the CCSDS standard (131.3).
>               # The boxes labeled "variable coding and modulation"
>                 contain no coding and no modulation. I think you mean
>                 VCM control.
>               # 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.
>           + Incomplete
>               # Few of the salient features of the VCM protocol are
>                 actually present in the figure. The VCM header is
>                 transmitted with pi/2-BPSK modulation, for example.
>                 The pilots are optional. The header has two parts, a
>                 sync marker and a signaling structure (PLS or frame
>                 descriptor). The frame descriptor is protected with a
>                 (32,6) code. All of that is missing.
>               # The input to the "VCM suite" is not labeled. The
>                 interfaces are the most important part of showing how
>                 things fit together.
>               # The output of the "VCM suite" is not labeled. Again,
>                 that should be the important part.
>               # No VCM control is shown as an input to the TM codes.
>               # No VCM control is shown for the pilots.
>               # No VCM control is shown for the slicer.
>               # Arrows showing direction of flow are missing throughout.
>
>      ----Jon
>
> *Jon Hamkins*
> Chief Technologist, Communications, Tracking, and Radar Division
> *O* 818-354-4764   | *M* 626-658-6220
>
> *JPL*   |   jpl.nasa.gov
>
> On 11/10/2021 11:58 PM, Andrea.Modenini at esa.int wrote:
>
>     FYI
>
>     *ESA - European Space Agency*
>     *Ph.D. Andrea Modenini**
>     TT&C Communications Systems Engineer***
>     TT&C and PDT Systems & Techniques Section (TEC-EST)
>     RF Systems Division*
>     ESTEC*
>     Keplerlaan 1, PO Box 299
>     NL-2200 AG Noordwijk, The Netherlands_
>     _andrea.modenini at esa.int | www.esa.int
>     <https://urldefense.us/v3/__http:/www.esa.int/__;!!PvBDto6Hs4WbVuu7!c_W6kQBKFsU715uHT0ZbEI-Zxyzva6CZAw_475CJiUtC49HEKgcsDEvKn5iiAOkOz9Y62n8$>
>     T +31 71 56 53439, M +31 6 484 56 527
>     ----- Forwarded by Andrea Modenini/estec/ESA on 11-11-21 08:57 -----
>
>     From: "Shames, Peter M\(US 312B\) via CESG-All"
>     <cesg-all at mailman.ccsds.org> <mailto:cesg-all at mailman.ccsds.org>
>     To: "CCSDS Engineering Steering Group - CESG All"
>     <cesg-all at mailman.ccsds.org> <mailto:cesg-all at mailman.ccsds.org>
>     Cc: "EXTERNAL-Pietras, John V\(US 332C-Affiliate\)"
>     <john.pietras at gst.com> <mailto:john.pietras at gst.com>, "SEA-SA"
>     <sea-sa at mailman.ccsds.org> <mailto:sea-sa at mailman.ccsds.org>
>     Date: 10-11-21 23:55
>     Subject: [Cesg-all] FW: [EXTERNAL] WebEx meeting invitation:
>     SCCS-ARD update review scheduled for Tuesday, 23 Nov, 2021 at 0700
>     AM PST
>     Sent by: "CESG-All" <cesg-all-bounces at mailman.ccsds.org>
>     <mailto:cesg-all-bounces at mailman.ccsds.org>
>
>     ------------------------------------------------------------------------
>
>     Dear CCSDS AD and WG chairs,
>
>     The review of the SCCS-ARD has been scheduled for Tuesday, 23 Nov,
>     2021 at 0700 AM PST.  The draft of the document, which is in
>     rough, “track changes”, form is available on-line.  The proposed
>     updates to the ABA subsections of sections 4, 5, and 6 (except for
>     the security-specific subsections) and posted the draft to the CWE at:
>
>     https://cwe.ccsds.org/sea/docs/SEA-SA/Draft%20Documents/SCCS-ARD-ADD%20Revisions%202020/SCCS-ARD%20draft%20documents/SCCS-ARD-901x1p1_10-211108.doc?d=wd389d0c8026d47a591fbc35f2e261b58
>     <https://urldefense.us/v3/__https:/cwe.ccsds.org/sea/docs/SEA-SA/Draft*20Documents/SCCS-ARD-ADD*20Revisions*202020/SCCS-ARD*20draft*20documents/SCCS-ARD-901x1p1_10-211108.doc?d=wd389d0c8026d47a591fbc35f2e261b58__;JSUlJSU!!PvBDto6Hs4WbVuu7!YAgXpQsrLJbeeQgotEG0WUNrvYYDosRiqy6GyJr5YS38sxD0qn-wbyDWHlnAyZkngUHY_hIq$>
>
>     Feel free to download this and review the sections that are of
>     interest most interest to you (or all of it if you wish).  If
>     there are members of your WG who can usefully contribute to this
>     review please feel free to invite them as well.
>
>     The Space Communications Cross Support Architecture document
>     (SCCS-ARD) is a cross-cutting Magenta Book that largely covers the
>     SLS, SIS, CSS, and SEA areas and their working groups.  We have
>     being working on an update to this document that primarily covers
>     what are called “ABA” mission configurations, which are those that
>     involve a single mission ops center, a single spacecraft, and a
>     ground station.  The Solar System Internet (SSI) configurations,
>     which involve multiple spacecraft, mission centers, and comm
>     assets, and use the DTN (or IP) protocols, will be in a future
>     update that builds on this foundation.
>
>     There have been a number of changes to the CCSDS standards
>     landscape since the last edition was published.  These include:
>
>       * USLP protocol
>       * The “VCM suite” of variable coding and modulation standards
>       * New CSTS services
>       * New Service Management standards
>       * Updates to the Synch and Channel coding specs, the liberal
>         approaches
>       * New security features in several sections
>
>     In addition to these new / updated standards we wish to address
>     the following issues as well:
>
>       * Improved handling of cross references from the Services
>         viewpoint to the protocol stack details (interface binding
>         signatures)
>       * Revised section structures and cross referencing
>       * Inclusion of “recommended” options and clarification of
>         optional and mandatory features
>       * Discussion of incomplete / optional capabilities like forward
>         file service, handling of details of complexities like MAP
>         service and VC/MC multiplexing, COP on the USLP return link,
>         and CADUs in FF-CSTS given new Pseudo-randomized “Only Idle
>         Data” (OID) frames
>
>     Hope to see you at this review.
>
>     Thanks, Peter Shames & John Pietras
>
>     *From: *Peter Shames <messenger at webex.com>
>     <mailto:messenger at webex.com>*
>     Reply-To: *Peter Shames <peter.m.shames at jpl.nasa.gov>
>     <mailto:peter.m.shames at jpl.nasa.gov>*
>     Date: *Thursday, November 4, 2021 at 3:07 PM*
>     To: *Peter Shames <peter.m.shames at jpl.nasa.gov>
>     <mailto:peter.m.shames at jpl.nasa.gov>*
>     Subject: *[EXTERNAL] (Forward to others) WebEx meeting invitation:
>     SCCS-ARD update review
>
>     You can forward this invitation to others.
>
>     Hello,
>
>     Peter Shames invites you to join this WebEx meeting.
>
>     *SCCS-ARD update review*
>
>     Tuesday, November 23, 2021
>
>     7:00 AM  |  (UTC-07:00) Pacific Time (US & Canada)  |  1 hr 30 mins
>
>     Meeting number (access code): 2761 585 8804
>
>     Meeting password: 9JRpYBGHp72
>
>     Join meeting
>     <https://jpl.webex.com/jpl/j.php?MTID=m19aa1606d8ed2742fa89cd2d8d4b0afa>
>
>     *More ways to join:*
>
>     *Join from the meeting link*
>
>     https://jpl.webex.com/jpl/j.php?MTID=m19aa1606d8ed2742fa89cd2d8d4b0afa
>     <https://jpl.webex.com/jpl/j.php?MTID=m19aa1606d8ed2742fa89cd2d8d4b0afa>
>
>     *Join from a video system or application*
>
>     Dial 27615858804 at jpl.webex.com <%20sip:27615858804 at jpl.webex.com>
>
>     You can also dial 207.182.190.20 and enter your meeting number.
>
>     *Join by phone*
>
>     +1-510-210-8882 USA Toll
>
>     +44-203-457-5798 U.K. Toll
>
>     Global call-in numbers
>     <https://jpl.webex.com/jpl/globalcallin.php?MTID=m5e38422f279e390de6b43d836a8711d0>
>
>     *Local: 818-35(4-4044)*
>
>     *Toll Free: 844-JPL-WEBX (844-575-9329)*
>
>     Can't join the meeting?
>
>     IMPORTANT NOTICE: Please note that this Webex service allows audio
>     and other information sent during the session to be recorded,
>     which may be discoverable in a legal matter. By joining this
>     session, you automatically consent to such recordings. If you do
>     not consent to being recorded, discuss your concerns with the host
>     or do not join the session.
>
>      [attachment "Webex_Meeting.ics" deleted by Andrea
>     Modenini/estec/ESA] _______________________________________________
>     CESG-All mailing list
>     CESG-All at mailman.ccsds.org
>     https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg-all
>     <https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg-all__;!!PvBDto6Hs4WbVuu7!c_W6kQBKFsU715uHT0ZbEI-Zxyzva6CZAw_475CJiUtC49HEKgcsDEvKn5iiAOkOJm26tok$>
>
>     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 at esa.int).
>
>
>
>     _______________________________________________
>
>     SLS-CC mailing list
>
>     SLS-CC at mailman.ccsds.org
>
>     https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-cc__;!!PvBDto6Hs4WbVuu7!c_W6kQBKFsU715uHT0ZbEI-Zxyzva6CZAw_475CJiUtC49HEKgcsDEvKn5iiAOkOmu4K-Qo$  <https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-cc__;!!PvBDto6Hs4WbVuu7!c_W6kQBKFsU715uHT0ZbEI-Zxyzva6CZAw_475CJiUtC49HEKgcsDEvKn5iiAOkOmu4K-Qo$>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-cc/attachments/20211129/7cc91e12/attachment-0001.htm>


More information about the SLS-CC mailing list