[Cesg-all] Results of CESG Polls closing 2 August 2019

Mon Aug 5 19:35:54 UTC 2019

CESG E-Poll Identifier:  CESG-P-2019-07-002 
Approval to release CCSDS 133.0-P-1.1, Space 
Packet Protocol (Pink Book, Issue 1.1) for CCSDS Agency review
Results of CESG poll beginning 19 July 2019 and ending 2 August 2019:

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

     Erik Barkley (Approve with Conditions):  1) 
The SANA Registry section needs to be properly 
populated before the book goes out for agency 
reviews.  Please see CCSDS 313.2-Y-1,  section, 2.3 for guidance.

     Peter Shames (Approve with 
Conditions):   There are four items that must be 
addressed.  See attached PID form.

Strongly recommend that the SANA registry section 
be amended to be simple and informative so that 
the document can go out for agency review without delay.
This is acceptable ONLY on the condition that the 
work to formally specify the registry, as called 
for in CCSDS Procedures for SANA Registry 
Specification, CCSDS 313.2-Y-1, Sec 3.2, be initiated immediately.

     Jonathan Wilmot (Approve with Conditions):  1.      Section 1.6.1.3
a.      application process identifier, APID: 
Suggest rewording The field in the packet 
primary header that uniquely identifies a stream 
of packets (indicates source, destination, or type)
to
The field in the packet primary header that 
uniquely identifies a stream of packets 
(indicates source, destination, or type) within 
the scope of a mission Is the term real 
subnetwork more appropriate? In section 2.1.1 
the term enterprise is used, in section 2.1.3 
single naming domain is used. The APID scope 
should have consistent terms. Also note that as 
implemented in ECSS PUS and NASA cFS, the 
secondary header is also needed to uniquely identify a stream of packet.

2.      Figure 2-1 a.   Might SPP also be 
exchanged as the payload using AMS? I would 
expect this to be the nominal use. The nominal 
use of a SPP packet is as the atomic application 
data unit to be exchanged as shown in Figure 2-2. 
AMS would be an Underlying Layer.
b.      Might AMS use TCP/IP or UDP/IP directly 
bypassing BP? c.        Section 2.4 SERVICES ASSUMED FROM LOWER LAYERS
Is When operating over space links, SPP relies 
on the Packet Services provided by the Space Data 
Link Protocols (i.e., TM, TC, AOS, Proximity-1, 
and USLP
 in agreement with figure 2-1?

3.      2.1.2 Protocol Features
a.      Just a comment. The nominal case for 
packet length is fixed. Many systems use the APID 
(and secondary header) to look up the fixed 
length format of the payload data. Flight systems 
map APIDs directly to a fixed data structure, and 
ground systems map it directly to a fixed length 
XTCE definition, or other fixed format. Variable 
length packets are a special case and are 
typically avoided due to parsing overhead and 
non-determinism on storage and bandwidth.
4.      3.4.2.4 Data Loss Indicator 
a.      I am confused by the statement 
and be 
used consistently by all parties involved in the 
implementation. When the service provides the 
loss indicator not all application will care or 
use the indication.  Are they then inconsistent 
implementations, or is it only that the SAP is 
consistent within a mission scope?

5.      4.1.2.2.2  Suggest rewording other 
packet structures to other packet primary header structures
6.      4.1.2.4.3.4 Suggest rewording A 
re-setting of the Packet Sequence Count before 
reaching 16383 shall not take place unless it is 
unavoidable to A re-setting of the Packet 
Sequence Count before reaching 16383 shall not 
take place unless it is unavoidable due to 
off-nominal operations Typically this should 
only occur due to a reset or other fault 
condition as you indicate in the notes.

7.      4.3.3.3 Just a question. If the 
receiving user of the APID uses the Packet 
Service, the received Packets shall be delivered 
intact to the user identified by the APID.  This 
would imply that the name space extension as 
allowed in the secondary header is not a valid 
Packet Service SAP. Following that means that 
NASAs cFS and ECSS PUS do not have valid SAPs. 
Are there any new spacecraft implementing a valid SAP?

8.      5.2 Table 5-1: Protocol Configuration Parameters
a.      Would table 5-1 have any mention/link to 
use of any SANA registered Packet Secondary Header?

9.      No additional comments on SANA 
considerations as they are well covered by others

  All of these can wait until agency review is in 
progress as these would be my comments during that review phase.

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-07-003 
Approval to release CCSDS 133.1-P-2.1, 
Encapsulation Packet Protocol (Pink Book, Issue 2.1) for CCSDS Agency review
Results of CESG poll beginning 19 July 2019 and ending 2 August 2019:

                 Abstain:  0 (0%) Approve 
Unconditionally:  6 (85.71%) (Barkley, Merri, Behal, Shames, Calzolari, Wilmot)
Approve with Conditions:  1 (14.29%) (Burleigh)
Disapprove with Comment:  0 (0%)
CONDITIONS/COMMENTS:

     Erik Barkley (Approve Unconditionally):   A 
comment, not a condition.  The SANA registry 
section notes that this is just modifying the 
names of existing registries.  Nonetheless as 
this is replacing the Encap Packet Protocol book 
extant, it seems that this should have the full 
description of the registries involved including update policies., etc.
     Peter Shames (Approve 
Unconditionally):   Initiate the work to change 
the registry names immediately, following the 
procedures in the CCSDS Procedures for SANA 
Registry Specification, CCSDS 313.2-Y-1, Sec 3.2.

     Scott Burleigh (Approve with 
Conditions):   Excellent book, but I saw one 
thing that I think is an error and might confuse 
the implementer: in 4.1.1.1(b) I believe 
"Encapsulation Protocol Data Unit" should instead 
be "Encapsulated Protocol Data Unit" or 
"Encapsulated Data Field".  I think the 
Encapsulation Packet itself, including its 
header, is the "Encapsulatoin Protocol Data Unit".

Total Respondents:  7

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-07-004 
Approval to release CCSDS 902.12-R-1, Common Data 
Entities (Red Book, Issue 1) for CCSDS Agency review
Results of CESG poll beginning 19 July 2019 and ending 2 August 2019:

                 Abstain:  1 (14.29%) (Calzolari)
Approve Unconditionally:  3 (42.86%) (Barkley, Burleigh, Wilmot)
Approve with Conditions:  3 (42.86%) (Merri, Behal, Shames)
Disapprove with Comment:  0 (0%)
CONDITIONS/COMMENTS:

     Mario Merri (Approve with Conditions):   Same as MOIMS DAD.

     Bigette Behal (Approve with 
Conditions):   The name of the document is 
misleading on its scope: the book    on ly deals 
with Service Management common data entities.

Therefore, rename the book so that its name reflects its real scope.

     Peter Shames (Approve with Conditions):   See attached PID.

Total Respondents:  7

All Areas responded to this question.

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

* * * * * * * * * * * * * * * * * * * * * * * *