[Sls-rfm] [EXTERNAL] Re: [SLS-CC] 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
Wed Dec 1 20:00:26 UTC 2021
Okay, sounds good. I hope we can find a time that the C&S/RFM chairs and
champions of the involved standards can be present.
I am requesting the meeting so that I can describe my concerns and
discuss a way to reach consensus. I suggest a one-hour block at the
beginning for me to present them, in a two-hour meeting. This
conversation will quickly get at the issue of the “suite” label, so I
think that fits in with Peter's plan, and there are a number of
unrelated fundamental issues relating to factual errors, omissions,
complexity, etc., as well.
----Jon
*Jon Hamkins*
Chief Technologist, Communications, Tracking, and Radar Division
*O* 818-354-4764 | *M* 626-658-6220
*JPL* | jpl.nasa.gov
On 11/30/2021 10:32 AM, Shames, Peter M (US 312B) wrote:
>
> Thanks Jon. I will fire off a Doodle to pick a time for a Webex.
>
> As far as I am concerned we need to deal with the fundamental issues
> that I raised. The handling of the details in the document will be a
> direct result of that discussion.
>
> Thanks, Peter
>
> *From: *Jon Hamkins <Jon.Hamkins at jpl.nasa.gov>
> *Date: *Monday, November 29, 2021 at 7:29 PM
> *To: *Peter Shames <peter.m.shames at jpl.nasa.gov>, Space Link Coding &
> Synchronization Working Group <sls-cc at mailman.ccsds.org>,
> "sls-rfm at mailman.ccsds.org" <sls-rfm at mailman.ccsds.org>
> *Cc: *"Ignacio.Aguilar.Sanchez at esa.int" <Ignacio.Aguilar.Sanchez at esa.int>
> *Subject: *Re: [EXTERNAL] Re: [SLS-CC] Fw: WebEx meeting invitation:
> SCCS-ARD update review scheduled for Tuesday, 23 Nov, 2021 at 0700 AM PST
>
> 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>
> <mailto:sls-cc-bounces at mailman.ccsds.org> on behalf of Jon Hamkins
> via SLS-CC <sls-cc at mailman.ccsds.org>
> <mailto:sls-cc at mailman.ccsds.org>
> *Reply-To: *Jon Hamkins <jon.hamkins at jpl.nasa.gov>
> <mailto: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> <mailto:sls-cc at mailman.ccsds.org>,
> "sls-rfm at mailman.ccsds.org" <mailto:sls-rfm at mailman.ccsds.org>
> <sls-rfm at mailman.ccsds.org> <mailto:sls-rfm at mailman.ccsds.org>,
> CCSDS Engineering Steering Group - CESG All
> <cesg-all at mailman.ccsds.org> <mailto: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.
>
> 1. The phrase "VCM suite"
>
> 1. 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.
> 2. Recommendation: Remove this phrase in all places and
> replace with "the VCM protocol."
> 3. Justification
>
> 1. 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.
> 2. 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.
> 3. 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."
> 4. 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.
>
> 2. Table 6-1 organization.
>
> 1. Description: Table 6-1 lists three references for the VCM
> "Suite": 131.2, 131.3, and 431.1.
> 2. 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.
> 3. Justification
>
> 1. Books that are the same type of thing are treated
> differently in the table.
>
> 1. 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.
> 2. 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).
>
> 2. Books that are different are treated as though they
> are the same in the table
>
> 1. 131.2, 131.3, and 431.1 cannot be listed as though
> they are the same type of thing
> 2. 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.
>
> 3. This would be consistent with the rest of the table.
>
> 3. Table 6-1 "space-to-ground links".
>
> 1. Description: The table has a left-column heading labeled
> "Space-to-Ground Links."
> 2. Recommendation:
>
> 1. Remove or reword "Space-to-Ground Links"
>
> 3. Justification:
>
> 1. This may be outdated terminology, given our renewed
> interest in allowing a variety of link directions for
> the standards.
> 2. 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?
>
> 4. Figure 6-1
>
> 1. 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.
> 2. 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.
> 3. Justification: As drawn, this figure is not clear and
> bordering on inaccurate.
>
> 1. 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.
> 2. 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.
> 3. VCM is a standard about both coding and modulation and
> so should be drawn to encompass the coding and
> modulation functions.
>
> 5. Section 6.1.2.2.1
>
> 1. Description. This section:
>
> 1. 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."
> 2. Refers to 131.2 and 131.3 as "VCM standards"
> 3. Says that 431.1 subsumes the functionality of 131.2
> and 131.3
>
> 2. Recommendation: Rewrite the paragraph from scratch to
> include these features
>
> 1. 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.
> 2. 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.
>
> 3. Justification:
>
> 1. 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.
> 2. 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.
> 3. 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.
>
> 6. Figure 6-2
>
> 1. Description. The figure purports to show component
> standards of "the VCM suite."
> 2. Recommendation:
>
> 1. Remove this figure from the SCCS-ARD.
>
> 3. Justification. This figure is unnecessary, redundant,
> artificially complex, misleading, and incomplete.
>
> 1. Unnecessary
>
> 1. There is no "VCM suite."
> 2. 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.
>
> 2. Redundant, artificially complex
>
> 1. 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.
> 2. The things that are common -- functions like
> slicing, ASM, modulation, pilot -- are drawn
> multiple times, giving the impression that they
> are different.
> 3. 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.
>
> 3. Misleading
>
> 1. 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.
> 2. The slicer for DVB is shown within the ETSI
> standard, when it is really part of the CCSDS
> standard (131.3).
> 3. The boxes labeled "variable coding and modulation"
> contain no coding and no modulation. I think you
> mean VCM control.
> 4. 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.
>
> 4. Incomplete
>
> 1. 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.
> 2. The input to the "VCM suite" is not labeled. The
> interfaces are the most important part of showing
> how things fit together.
> 3. The output of the "VCM suite" is not labeled.
> Again, that should be the important part.
> 4. No VCM control is shown as an input to the TM codes.
> 5. No VCM control is shown for the pilots.
> 6. No VCM control is shown for the slicer.
> 7. 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:
>
> 1. USLP protocol
> 2. The “VCM suite” of variable coding and modulation standards
> 3. New CSTS services
> 4. New Service Management standards
> 5. Updates to the Synch and Channel coding specs, the liberal
> approaches
> 6. New security features in several sections
>
> In addition to these new / updated standards we wish to
> address the following issues as well:
>
> 1. Improved handling of cross references from the Services
> viewpoint to the protocol stack details (interface binding
> signatures)
> 2. Revised section structures and cross referencing
> 3. Inclusion of “recommended” options and clarification of
> optional and mandatory features
> 4. 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-rfm/attachments/20211201/bedcc517/attachment.htm>
More information about the SLS-RFM
mailing list