[Cesg-all] Results of CESG Polls closing 29 January 2020

Fri Jan 31 18:10:03 UTC 2020

CESG E-Poll Identifier:  CESG-P-2019-12-002 
Approval to release CCSDS 131.3-P-1.1, CCSDS 
Space Link Protocols over ETSI DVB-S2 Standard 
(Pink Sheets, Issue 1.1) for CCSDS Agency review
Results of CESG poll beginning 31 December 2019 and ending 29 January 2020:

                 Abstain:  1 (16.67%) (Merri)
Approve Unconditionally:  2 (33.33%) (Barkley, Calzolari)
Approve with Conditions:  3 (50%) (Shames, Burleigh, Wilmot)
Disapprove with Comment:  0 (0%)
CONDITIONS/COMMENTS:

     Erik Barkley (Approve 
Unconditionally):   Comments -- Technically I 
have no concerns re the pink sheets.
Programmatically, from the point of view of 
considering things like AOS frames for uplink in 
general, I do have a concern one recommendation 
quite "easily" allows AOS uplink but other 
recommendations go out of their way to enforce 
distincitions as to whether or not AOS frames are 
allowed in only a certain direction (downlink). 
As such I think we should get a consistent 
"profile" across the various link level 
standards.   Part of this is also somewhat just 
self-interest -- it would be nice for FF-CSTS to 
not have to indicate stipulations as to 
applciability as to when various frame types are 
or are not allowed for uplinking.

     Peter Shames (Approve with Conditions):  Facts:

The mods to the DVB-S2 coding and synch document have the following effect:

1)      Change the applicability of the coding 
the synchronization schemes as defined in the 
DVB-S2 standard from telemetry / downlink only, 
to downlink, uplink, and cross link (plus, as 
implied, maybe proximity link and surface-to-surface link too)

2)      Add support for USLP (and also, incidentally, AOS for uplink use)

3)      Add support for Space Research Service 
(SRS) use, in addition to the current Earth 
Exploration Service (EESS) applications

4)      Limit use of USLP to only the fixed length frame option

In essence, the use cases of the DVB-S2 would be 
extended from downlink only, to those that are 
neutral to link directionality and independent of link type.

Statement:

These changes to CCSDS 131.3-B-1 finally open up 
the possibility of using the AOS and USLP 
protocols in the forward and cross-link 
applications, as well as for downlink / 
telemetry, which is what these two protocols have 
always been designed to do.  This allows them, as 
they were designed, to be deployed in modes that 
are neutral to directionality as well as to link 
types.  As such this is a good thing and approval 
of this spec would mean that now these protocols 
and an underlying coding and synchronization 
(only DVB-S2 in this formulation, but potentially 
others) would be available to a wider range of 
missions and applications. This is a fundamental 
change and I wholeheartedly endorse it.

However, approving this change for only this 
DVB-S2 coding and synch standard leaves the users 
of these two powerful space data link standards 
(AOS and USLP) without the ability to choose the 
completely appropriate core CCSDS TM coding and 
synch standards as well.  We already have 
missions, such as the Lunar and Gateway, that, in 
compliance with the International Communication 
System Interoperability Standards (ICSIS), are 
planning to use AOS/USLP for forward, proximity 
and cross-link USLP over the LDPC specs that are 
documented in the TM synch and channel coding 
book, CCSDS 131.0-B-3.  A set of changes to that 
doc, which were first proposed in detail more 
than two years ago, have stalled and not moved 
forward.  These changes are hardly any more 
complex than those in this document and it is 
past time to complete the work to get them approved and published as well.

Approval of this spec is therefore conditional on 
completion of the identical changes to the TM 
Synch and Channel Coding spec, CCSDS 131.0-B-3, 
thus allowing AOS and USLP to be used over these 
codes for forward, proximate, and cross link purposes.

In my opinion it would be wise to do likewise 
with the accommodation of USLP variable length 
frames over the TC synch and channel coding 
standard as well.  There is really no technical 
reason why all of the CCSDS frame types and 
suitable codes should not be available to all 
missions.  These limitations that tie us to 30+ 
year old distinctions are just holding CCSDS 
back, and our users are moving out on their own 
to use what we have provided in more functional 
ways than we have, as yet, approved.

     Scott Burleigh (Approve with 
Conditions):   I support Peter Shames's position 
with regard to the release of these Pink 
Sheets.  The document itself seems fine to 
me.  In order to defend the continuing relevance 
of CCSDS to upcoming flight missions, however, 
this new applicability to AOS and USLP links 
should be extended to Telemetry Synch and Channel Coding as well.

     Jonathan Wilmot (Approve with 
Conditions):  I also agree with Peter and Scotts 
comments, and include an additional specific comment.
It should be an overall goal to provide for 
common operational interfaces for Managed 
parameters published in CCSDS standards. To that 
end, more specific common data types should be 
provided: signed/unsigned Integer, Boolean, 
Enumerations (ON, OFF), (Short, Normal, Both) 
, 
float, etc. This would allow the exchange of MIB 
parameters based on common names and types 
between organizations. The binary encoding of 
those MIBs could be specified in CCSDS Electronics data sheets, or XTCE.

Total Respondents:  6

All Areas responded to this question.

SECRETARIAT INTERPRETATION OF RESULTS:  Approved with Conditions
PROPOSED SECRETARIAT ACTION:            Generate 
CMC poll after conditions have been addressed

* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier:  CESG-P-2019-12-003 
Approval to release CCSDS 211.0-P-5.1, 
Proximity-1 Space Link ProtocolData Link Layer 
(Pink Sheets, Issue 5.1) for CCSDS Agency review
Results of CESG poll beginning 31 December 2019 and ending 29 January 2020:

                 Abstain:  1 (16.67%) (Merri)
Approve Unconditionally:  5 (83.33%) (Barkley, 
Shames, Burleigh, Calzolari, Wilmot)
Approve with Conditions:  0 (0%) Disapprove with Comment:  0 (0%)
CONDITIONS/COMMENTS:

     Peter Shames (Approve Unconditionally):  I 
assume that the incorrect reference for CCSDS 
320.0-M-7c1 will be rectified in "CTE Post-processing".

     Jonathan Wilmot (Approve 
Unconditionally):   My general comment that CCSDS 
defined MIBs should include unambiguous names 
with standard data types will be part of the agency review feedback.

Total Respondents:  6

All Areas responded to this question.

SECRETARIAT INTERPRETATION OF RESULTS:  Approved Unconditionally
PROPOSED SECRETARIAT ACTION:            Generate CMC poll

* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier:  CESG-P-2019-12-004 
Approval to publish CCSDS 350.8-M-2, Information 
Security Glossary of Terms (Magenta Book, Issue 2)
Results of CESG poll beginning 31 December 2019 and ending 29 January 2020:

                 Abstain:  0 (0%) Approve 
Unconditionally:  6 (100%) (Barkley, Merri, Shames, Burleigh, Moury, Wilmot)
Approve with Conditions:  0 (0%) Disapprove with Comment:  0 (0%)
CONDITIONS/COMMENTS:

     Erik Barkley (Approve Unconditionally):  A 
comment/question (not a condition):  Seems like 
it would make sense to have this in SANA rather 
than a book -- has that been considered? In terms 
of normative application the MB could still be 
normative in identifying SANA registry and the update/governance policy.

     Jonathan Wilmot (Approve 
Unconditionally):  I agree with Eric that 
glossaries would be better in SANA as they are 
living documents that will change over 
time.  Example: where would terms from BPsec be placed?

Total Respondents:  6

All Areas responded to this question.

SECRETARIAT INTERPRETATION OF RESULTS:  Approved Unconditionally
PROPOSED SECRETARIAT ACTION:            Generate CMC poll

* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier:  CESG-P-2019-12-005 
Approval to publish CCSDS 355.1-B-1, Space Data 
Link Security ProtocolExtended Procedures (Blue Book, Issue 1)
Results of CESG poll beginning 31 December 2019 and ending 29 January 2020:

                 Abstain:  1 (20%) (Merri)
Approve Unconditionally:  3 (60%) (Burleigh, Calzolari, Wilmot)
Approve with Conditions:  1 (20%) (Shames)
Disapprove with Comment:  0 (0%)
CONDITIONS/COMMENTS:

     Peter Shames (Approve with 
Conditions):   There are ambiguities in the test 
report and in the standard itself.  Most critical 
is that the descriptions in Sec 5.3 are ambiguous 
and confusing until you study the details in Sec 5.4.  This should be fixed.

Total Respondents:  5