[Cesg-all] Results of CESG poll closing 9 July 2010

[CCSDS Secretariat]

CESG E-Poll Identifier:  CESG-P-2010-06-001 Final approval of CCSDS 
521.0-B-1, Mission Operations Message Abstraction Layer (BLue Book, Issue 1)
Results of CESG poll beginning 19 June 2010 and ending 9 July 2010:

                  Abstain:  1 (16.67%) (Gerner)
  Approve Unconditionally:  2 (33.33%) (Thompson, Moury)
  Approve with Conditions:  3 (50%) (Shames, Barkley, Durst)
  Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

      Peter Shames (Approve with Conditions):  There are some 
ambiguous sections in the MAL document, as marked in the attached 
document.  Please clarify.

In addition, since the MAL does not explicit define all message 
structures and fields, down to the bit level, it appears that 
interoperability testing can only proceed if those mappings are 
agreed.  It is not clearly stated that this is the case, and the 
interop tests use a shared "Transport adapter implementation" and 
"Message transport" implementation.  Thus it appears that these 
implementations are not truly independent down to the "wire protocol".

I recognize that this is an inherent feature of the approach used to 
permit multiple technology mappings, but it does mean that the specs 
must be clear that this added mapping function is required and how it 
is to be provided.  Please review and clarify.

      Erik Barkley (Approve with Conditions):  1) Per CESG 
conclusions circa fall 2007, PICS Proforma statements are desired for 
CCSDS Bluebooks; some exceptions are recognized; strongly suggest 
adding at least a statement about compliance levels -- e.g., if an 
implementation of MAL does not include the PUBSUB pattern is that 
("lesser") implementation still interoperable with other MAL 
implementations for SEND, SUBMIT type patterns? If so, then do SEND, 
SUBMIT (up to some pattern short of PUBSUB) represent minimal MAL compliance?

2) Suggest re-consideration of RID ESA-1 (re timeout):  The rationale 
cited as being an implementation issue may be viewed as correct from 
the perspective that MAL is the final service to be implemented over 
such technologies as JMS, DDS. But, in fact, MAL's rasion d'etre is 
to offer seamless messaging across very different communications 
transport layers.  Stating that timeout is a local implementation 
issue then implies that MAL can only be run over those technologies 
that inherently include timeout indications. This seems to be at odds 
with the claim of operating over different transport 
technologies.  At a minimum, it seems that some requirement 
statements for underlying transport technologies needs to be 
included, but perhaps it is better to consider timeouts and include 
them in the state transitions so that services specifications making 
use of MAL are well aware of timeout considerations and what the MAL 
behavior will be in those situations.

3) The PUBSUB pattern may be lacking a bit in semantics.  What is the 
message/data persistence/purge policy? Pub/Sub patterns tend to make 
allowance for non-contemporaneous instances of software processes, 
which seems like a good idea for an end-to-end MAL involving long 
light-time signal propagation delays.  I didn't see any behavioral 
requirements about the broker persisting data that cannot be 
immediately delivered to the subscribing consumer(s)?  As I read the 
recommendation it implies that consumer and provider must be 
contemporaneously executing or the data is not delivered.  That does 
not seem to comport well with the set of services that are envisioned 
to be running on top of MAL.  It seems that to confidently build 
services using MAL these kinds of behaviors need to be stated (as 
opposed to being "discovery" exercises related to the local 
implementation which in fact may be rather disparate (terrestrial vs. 
long-haul deep space) and so, in aggregate, exhibit "interesting" 
emergent properties).

4) Perhaps an action for the secretariat:  do better informative vs. 
normative markings needs to be added re section 6?  It is unclear if 
the schema is normative -- presumably it is if XML is being utilized 
?  Presumably section 6.4 is informative or is this intended as 
normative statement of MAL Service?

5) There are some more minor comments which I hope to provide via a 
marked up copy of the document in the very near future.  If I fail to 
do so by 0 hrs UTC 16 Jul 2010 please consider that I am in a timeout 
state! -- ie., condition satisfied.

      Bob Durst (Approve with Conditions):  Although it is not a 
condition of approval for this document, the SIS AD notes that a 
(normative) MAL-to-AMS binding *should* be produced jointly by MAL 
and AMS experts.  Such a document will be helpful to those interested 
in using both the MAL and AMS specifications, and will likely be 
informative to the authors of those specifications.


Total Respondents:  6

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

      SOIS



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

* * * * * * * * * * * * * * * * * * * * * * * *
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 521x0b0_CESG_Approval-ps.pdf
Type: application/pdf
Size: 2104018 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/cesg-all/attachments/20100710/e45f6242/521x0b0_CESG_Approval-ps-0001.pdf