[Cesg-all] Results of CESG Polls closing 16 March 2015

Tue Mar 17 20:59:10 UTC 2015

CESG E-Poll Identifier: CESG-P-2015-02-001 
Approval to publish CCSDS 231.1-O-1, Short Block 
Length LDPC Codes for TC Synchronization and 
Channel Coding (Orange Book, Issue 1)
Results of CESG poll beginning 28 February 2015 and ending 16 March 2015:

                  Abstain:  1 (20%) (Taylor)
  Approve Unconditionally:  4 (80%) (Shames, Peccia, Barkley, Calzolari)
  Approve with Conditions:  0 (0%)
  Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

Nestor Peccia (Approve Unconditionally): As an 
Orange Book there is not a requirement for patent 
disclosures, but it would be appropriate to 
indicate whether any of these new approaches are, in fact, patented.

Total Respondents: 5
No response was received from the following Area(s):

SIS

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

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

CESG E-Poll Identifier: CESG-P-2015-02-002 
Approval to publish CCSDS 524.1-B-1, Mission 
Operations Message Abstraction LayerSpace Packet Binding (Blue Book, Issue 1)
Results of CESG poll beginning 28 February 2015 and ending 16 March 2015:

                  Abstain:  1 (25%) (Taylor)
  Approve Unconditionally:  2 (50%) (Peccia, Calzolari)
  Approve with Conditions:  1 (25%) (Shames)
  Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

Peter Shames (Approve with Conditions): This 
document is vastly improved beyond the original 
and does a credible job of providing a rather 
complete binding from the MAL abstract data types 
and message formats to a concrete set of data 
types and SPP compliant message formats.

There are, however, still a few loose ends that 
need to be tied down in order to ensure 
interoperability. They are flagged in the document and listed here:

1) The "mapping configuration parameter" set (Sec 
2.4.2 & Annex B) is a major element in 
interoperability, but it is listed as a "managed 
parameter" handled by some unspecified out of 
band agreement. Absent a way to acquire this key 
document interoperability is impossible.

2) There are several issues in the text that must 
be corrected, such as stating that the APID 
Qualifier, an integer field, is to include a "/" 
character, the use of Packet Type" does not align 
with SPP defined usage, the handling of security / authentication.

3) The handling of retransmission is left to 
"lower layers", but many CCSDS space link 
protocol deployments do not include such 
features. Is reliability, particularly of 
commanding, to be left to "lower layers", i.e. 
"bottom up" or is it a requirement applied by MO operations, top down?

4) The test report appears to be quite thorough, 
but one key element required for 
interoperability, that pesky "mapping 
configuration parameter" set, is not even 
mentioned. Also, the details of the test 
configuration leave a lot to the imagination and 
it is not clear how anyone other than those 
involved in the test could insert their own MAL / 
SPP component and test it out. See notes on test report for more details.

Total Respondents: 4
No response was received from the following Area(s):

CSS
SIS

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

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

CESG E-Poll Identifier: CESG-P-2015-02-003 
Approval to publish CCSDS 734.1-B-1, Licklider 
Transmission Protocol (LTP) for CCSDS (Blue Book, Issue 1)
Results of CESG poll beginning 28 February 2015 and ending 16 March 2015:

                  Abstain:  1 (25%) (Taylor)
  Approve Unconditionally:  2 (50%) (Peccia, Scott)
  Approve with Conditions:  1 (25%) (Shames)
  Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

Peter Shames (Approve with Conditions): LTP is 
defined to provide "optional reliability 
mechanisms on top of an underlying (usually data 
link) communication service". It appears to do 
just that, and the spec, in its current form, has 
been implemented, but there appear to be more 
than just a few loose ends in the spec and in the testing.

The following major issues have been identified:
1) Unlike the way that TCP provides "reliable, 
deliver once, in order, without omission" 
services above IP, LTP only provides "reliable". 
The other features must be provided, somewhat awkwardly, in other ways.
2) TCP includes user data segmentation and 
re-assembly features, LTP describes, as a user 
feature, a function called "service data 
aggregation", but this feels like it was just 
tacked on when it probably should be a formal, if 
optional, part of the LTP services.
3) From a deployment point of view the handling 
of the various registries that are described, the 
LTP Engine ID, in particular, seems really weakly 
specified. There are SANA registries associated 
with this spec, but there do not appear to be 
defined policies and there is just a global 
namespace for all agencies, centers, missions, 
and end points. This could be better thought out 
and could leverage the existing MACAO or SCID registry processes.
4) Much discussion is made of deploying LTP over 
UDP in this document. Given that this is a CCSDS 
document the focus ought to be on deployment of 
CCSDS space data links, not over UDP. UDP, in 
this context, is just a virtual, single-hop, space data link.
5) Readability of the document, in its present 
form, really suffers because it switches back and 
forth between specifying the standard, 
referencing (imperfectly) the RFC 5326 it derives 
from, and dealing with ambiguities between the two.
6) There are many NOTES in the document that read 
as though they really should be cast as 
requirements, e.g. NOTE 2 in 3.5.1 "the only 
requirement imposed by LTP is that every session 
initiated by an LTP engine must be uniquely 
identified by the session ID.", or NOTE 1 in Sec 
4.4 "Section 8.1 of RFC 5326 contains a state 
transition diagram for sending LTP engines."
7) At various points both SANA and IANA 
registries are referenced, and there is a SANA 
registry section. However, looking at both of 
these sets of registries it appears that neither 
of them have clearly stated registration policies 
nor identified "experts". How these will work in 
a production environment is not apparent and the 
LTP engine ID is synched with the allocations in 
the Bundle Protocol Compressed Bundle Header 
Encoding Node Numbers registry for reasons that are unclear.
8) Security mechanisms are also very weakly, and 
somewhat confusingly, specified. There is a 
"hook" for security in the form of an 
authentication mechanism, but there is little in 
the way of "scaffolding" to make it work. Part of 
this, of course, is due to the fact that CCSDS as 
a whole has yet to completely specify such scaffolding.
9) There is a source of confusion in that LTP, in 
this document, is described as providing 
"delivery across a particular data link is 
provided by a layer-(N-1) service such as the 
CCSDS Encapsulation Service." The issue, of 
course, is that Encap (and SPP) does not provide 
such a data link service, it provides a data 
packaging "shim" that must be inserted itself 
into an underlying data link. It does state this 
clearly in Sec 3.4: "LTP should be deployed 
across individual space data links and should be 
terminated at the ends of each space data link." 
At other points the focus on ENCAP and SPP as the 
shims for getting LTP SDUs into a space data link confuse the discussion.

This protocol clearly provides features that 
should be of value for providing reliability over 
what may be unreliable underlying space data 
links. It really needs to have these ambiguities 
and loose ends cleaned up in order to fit better 
into the rest of the CCSDS recommended standards.

Total Respondents: 4
No response was received from the following Area(s):

CSS
SLS

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

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

CESG E-Poll Identifier: CESG-P-2015-02-004 
Approval to publish CCSDS 880.0-G-2, Wireless 
Network Communications Overview for Space Mission 
Operations (Green Book, Issue 2)
Results of CESG poll beginning 28 February 2015 and ending 16 March 2015:

                  Abstain:  0 (0%)
  Approve Unconditionally:  4 (100%) (Shames, Peccia, Barkley, Taylor)
  Approve with Conditions:  0 (0%)
  Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

Peter Shames (Approve Unconditionally): Very 
comprehensive document, but will likely be OBE 
within 5 years because of rapidly evolving commercial standards.

Total Respondents: 4
No response was received from the following Area(s):

SLS
SIS

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 524x1b0_CESG_Approval-SEA.pdf
Type: application/pdf
Size: 2064614 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/cesg-all/attachments/20150317/2ab903a1/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MO SPP Prototype Test Report-v1-0-ps.doc
Type: application/msword
Size: 1892352 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/cesg-all/attachments/20150317/2ab903a1/attachment.doc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 734x1b0_CESG_Approval-SEA.pdf
Type: application/pdf
Size: 1354325 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/cesg-all/attachments/20150317/2ab903a1/attachment-0001.pdf>