[Cesg-all] Results of CESG polls closing 20 December 2012

[CCSDS Secretariat]

CESG E-Poll Identifier:  CESG-P-2012-11-006 
Approval to release CCSDS 524.1-R-1,  Mission 
Operations Message Abstraction Layer—Space Packet 
Binding (Red Book, Issue 1) for CCSDS Agency review
Results of CESG poll beginning 30 November 2012 and ending 20 December 2012:

                  Abstain:  0 (0%)
  Approve Unconditionally:  2 (28.57%) (Peccia, Moury)
  Approve with Conditions:  4 (57.14%) (Shames, Barkley, Taylor, Calzolari)
  Disapprove with Comment:  1 (14.29%) (Scott)

CONDITIONS/COMMENTS:

      Peter Shames (Approve with 
Conditions):  This draft document contains a 
large number of ambiguities that should be 
rectified before it is released for agency 
review. See attached mark-up of the PDF file.

It is my belief, based on this review, that it 
would not be possible for two implementations 
created according to this spec to successfully 
interoperate without much additional information exchanging hands.

A summary of the major issues are these:

- Mappings from the input MAL abstract interface 
to the SPP fields is often ambiguous or ill-specified.
- Significant parts of the terminology is not clearly defined
- The use of BNF to describe the mapping rules, 
in the intended process, is inadequate to the task
- a number of fields are not identified as 
"optional" but then are treated as being able to 
be left out if they are NULL.  This sounds 
"optional" to me.  Many of these instances are ambiguous described.
- The normative encodings, which are finally 
defined in Annex B are never introduced earlier 
in the document, but they are essential to 
understanding how these mappings are to be done.

      Erik Barkley (Approve with Conditions):  In 
general, the notion of a compact MAL Header is 
not defined by MAL itself ie, CCSDS 521.  As 
various encodings are not included in the binding 
when mapping to the compact header it is unclear 
as to inter-operability with multiple bindings is 
achieved.  (Presumably MAL is to abstract such 
that multiple underlying transports can be 
bridged).   If there are impacts to 
interoprability via MAL to other bindings (e.g, 
MAL to AMS, MAL to JMS, etc), this needs to be 
indicated.  At a minimum a reference to binding 
inter-operability profiles should be included.

Section 3.1.3 states that all interaction 
patterns defined by MAL shall be supported. It is 
unclear  as to where the interaction patterns are 
being defined  -- presumably anything at the MAL 
layer and above will be making inquiries as to 
the supported interaction patterns and presumably 
be returned a "true" value as all interaction 
patterns are required to be "supported".  One of 
the interaction patterns is that of publication 
and subscription which requires some sort of 
broker infrastructure. Space packet protocol has 
no interaction patterns defined and no such 
infrastructure.  Therefore it appears that it 
would be this binding  book that establishes this 
infrastructure. But there is no such definition 
or discussion in this proposed recommendation. At 
a minimum this needs clarification and more 
likely requires definition in the proposed binding book.

Section 3.1.6.2 says that the MAL message header 
fields for received data shall be generated from 
the space packet primary header fields, the 
secondary header fields and some fields from the 
user data field. Please provide a reference to 
the exact definitions or table in the recommendation.

Section 3.1.6.4 indicates that "Some" QOS 
properties may be passed via a receive indication 
depending on the transport used to convey the 
space packets. It is vague as to what properties 
are being discussed and a reference is needed to 
the exact definitions. Also, it is unclear as to 
where the ultimate QOS properties are coming from 
as the space packet protocol in turn does not 
define this. It seems to be rather confusing 
situation of binding to transport to indicate 
that there is yet another underlying transport. 
Why are QOS parameters not treated directly by 
this binding recommendation? Presumably the MAL 
has already provided the abstraction and this is 
presumably getting to a concrete transport, correct?

4.4.6.2 Defines Network Zone encoding to be PTC 8 
--> UTF-8.  MAL bluebook states network zone is 
UTF-16.  Assuming it is not a compact MAL Header 
then the encoding occurs.  UTF-16  to UTF-8 
conversion is not specified or required.  The 
IDENTIFIER encoding pattern does not address 
this.   Please clarify and/or indicate the conversion requirements.

      Chris Taylor (Approve with 
Conditions):  It's not so clear how multiple 
messages are packed in a single space packet as 
there is no lenghth indicator in the secondary 
hearder. Given that the packets are typically 
missing limited to max 1K, I wonder if it make 
sense anypay to have more than 1 message per packet?

The secondary HDR of the SPP assumes that time is 
the first field, this is incomaptible with the proposed sec hdr format.

The ancillary data field of the SPP is not 
mentioned but this field is intended for the type 
of information beiung transferred?

      Gian Paolo Calzolari (Approve with 
Conditions):  Please addreess the following 
comments to solve inconsistencies with 133.0-B:
Figure 2-3: MO Service Framework above Space 
Packet Protocol ---> Based on following comments 
I do favor showing the interactions between 
layers; i.e. show the primitives mentioned in 
Table 3-2 between the two lowest boxes "Space 
Packet Protocol" and "MAL Space Packet Binding" 
and so on for other upper boxes as needed.
3.1 PROVIDED INTERFACE ---> I find confusing the 
definition of these primitives without a precise 
list opf paraments and I do favor a common 
description as the one used in clause 3.2.1.2 (with table) or similar.
4.2.2 VERSION NUMBER The field ‘Version Number’ 
shall be assigned with the value ‘0’. --> I think now it should refer to SANA.
4.2.3.1 The field ‘Type’ shall be assigned... 
---> The referenced table does not state the 
numerical value to be assigned but only the 
"mnemonic" type. Should SANA be addressed?
4.2.4 DATA FIELD HEADER FLAG  ---> This is not 
CCSDS terminology (is it ECSS?). The filed is 
named "Secondary Header Flag " in 133.0-B
4.2.5 APPLICATION PROCESS ID   The field ‘APID’ 
shall be assigned according to the Space Packet 
Protocol specification (reference [1]). ---> 
133.0 except the value for Idle Packets does not 
specify how this values are set. It looks to me 
that this clause should reference an input 
parameter from upper layer(s) as e.g. those in 
clause 3.1.4.2.  Note that in 133.0-B section 
"4.2.3 PACKET TRANSFER FUNCTION" and section 
"3.3.3.2 PACKET.request " it is expected to 
receive a fully formed space packet.
4.2.6 SEQUENCE FLAGS The field ‘Sequence Flags’ 
shall be assigned by the Space Packet Protocol 
layer.  ---> It looks to me that this clause 
should reference an input parameter from upper 
layer(s) as e.g. those in clause 3.1.4.2.  Note 
that in 133.0-B section "4.2.3 PACKET TRANSFER 
FUNCTION" and section "3.3.3.2 PACKET.request " 
it is expected to receive a fully formed space packet.
4.2.7 SEQUENCE COUNT The field ‘Sequence Count’ 
shall be assigned by the Space Packet Protocol 
layer. ---> It looks to me that this clause 
should reference an input parameter from upper 
layer(s) as e.g. those in clause 3.1.4.2. 
Alternatively can be part of the "MAL Space 
Packet Binding" internal processing. Note that in 
133.0-B section "4.2.3 PACKET TRANSFER FUNCTION" 
and section "3.3.3.2 PACKET.request " it is 
expected to receive a fully formed space packet.
4.2.8.1 The field ‘Packet Length’ shall be 
assigned by the Space Packet Protocol layer. ---> 
It looks to me that this clause should reference 
an input parameter from upper layer(s) as e.g. 
those in clause 3.1.4.2. Alternatively can be 
part of the "MAL Space Packet Binding" internal 
processing. Note that in 133.0-B section "4.2.3 
PACKET TRANSFER FUNCTION" and section "3.3.3.2 
PACKET.request " it is expected to receive a fully formed space packet.
4.3 SECONDARY HEADER ---> Please make clear that 
you are defining a secondary header for MAL 
purposes selecting option "b" of clause "4.1.3.2.1.5 " of 133.0-B.
4.5 MAL HEADER MAPPING --->  Some of the sub 
sections here defined should be moved into 
section 4.2.x as per my comments above.
4.5.2.1 a) ---> This looks in conflict with 
clause 4.5.4.1  a) as it looks as the same value 
of the SP primary header can be derived from two 
input parameters. Please clarify; e.g. state 
whether those two parameters are mutually exclusive in the MAL header.
A3.1 ---> Section 1.8 is not normative and it 
looks odd to include it in PICS. Recommed to 
convert it to a note or to include a relevant 
requirement in normative section (i.e. 3 onwards).

      Keith Scott (Disapprove with Comment):  I 
have the following issues with the document, 
listed in decreasing order of importance:

1. It seems like the intent of the MAL-to-Space 
Packet-Binding document, together with the MO 
Message Abstraction Layer (MAL service spec), is 
to define an "on-the-wire" protocol for 
implementing the services in the service 
specification over Space Packets.  As such I 
think it defines a protocol and hence requires an 
interoperability test report documenting two 
independently-developed and interoperable 
implementations that provide the full suite of 
services specified in the MAL service spec to go Blue.

2. Shouldn't the PICS explicitly require 
statements regarding the encoding of the various 
MAL message formats, not just some general 
statements about primary, secondary, and user 
fields?  This interacts with #1 above.

3. The binding only seems to specify SENDing and 
SUBMITting from the ground to space (via 
Telecommand Space Packets) and PUBLISHing from 
space to ground (publish is only via Telemetry).  Is this really the intent?

4. Binding MAL to space packets imposes the 
limitation that MAL protocol 'peers' be at most 
one hop away from each other (since space packets 
are not routed).  This perpetuates the legacy 
'single-hop' communications model instead of 
laying the foundations for the future (in 
general, multi-hop) Solar System Internet.


Total Respondents:  7

All Areas responded to this question.

SECRETARIAT INTERPRETATION OF RESULTS:  Disapproved
PROPOSED SECRETARIAT ACTION:            No Action

* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier:  CESG-P-2012-11-007 
Approval to publish CCSDS 401.0-B-22,  Radio 
Frequency and Modulation Systems—Part 1: Earth 
Stations and Spacecraft (Blue Book, Issue 22)
Results of CESG poll beginning 30 November 2012 and ending 20 December 2012:

                  Abstain:  1 (14.29%) (Scott)
  Approve Unconditionally:  6 (85.71%) (Shames, 
Peccia, Barkley, Taylor, Calzolari, Moury)
  Approve with Conditions:  0 (0%)
  Disapprove with Comment:  0 (0%)

Total Respondents:  7

All Areas responded to this question.

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

* * * * * * * * * * * * * * * * * * * * * * * *
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 524x1r0_CESG_Approval-SEA.pdf
Type: application/pdf
Size: 1082950 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/cesg-all/attachments/20121222/066d28b4/524x1r0_CESG_Approval-SEA-0001.pdf