[CMC] Re: MOIMS Resolution Nr 11 SM&C MAL, Common and Core approval as BB

[Adrian J. Hooke]

Nestor: three observations --

1. We already have a two hour slot (1315-1515 on Monday) on the CESG 
agenda  to discuss these kinds of concerns. Any residual issues will 
be brought to the attention of the CMC, but at this point in time it 
is NOT appropriate for you to "request to put this case as the 
highest priority item to be discussed next week at the CMC meeting" 
since its priority and need for CMC deliberation will be determined 
by the outcome of the prior CESG discussion.

2. The WG chairman's defensive characterization of Peter's motives is 
unhelpful. Peter was simply doing his job as an Area Director and was 
fulfilling a chartered responsibility of the CESG as a whole to 
provide a final review of documents that are being proposed for 
adoption as CCSDS Recommended Standards. As such, it is fully 
expected that he would be "uncoordinated from his own organisation". 
He also took a considerable amount of personal time to read a very 
complex series of documents and as a result produced an extensive set 
of polite and technical comments.  Attempting to disparage his 
technical dissent as being disrespectful of "human interoperability 
and cooperation" is itself highly disrespectful of that same 
condition, and is not a behavior that is appropriate for the CESG forum.

3.  All of the responses (snipped and highlighted below) seem to 
point to a common key to the disagreement,  which appears to be the 
dependence of these documents on another yet-to-be-issued "technology 
bindings" standard. If that is indeed the problem, then perhaps the 
SM&C Working Group needs to produce a better map of its overall 
documentation relationships? And perhaps this current crop of SM&C 
documents should be held at "Red" status until the complete set of 
specifications required to achieve full international 
interoperability has been produced and reviewed?

Best regards
Adrian

> >>>> You are completely wrong here Peter, they do _not_ leave anything to the
>implementor but leave it to another language/transport binding book. The
>combination of the two provide the completely interoperable implementation.
>This is stated in sections 2.5 and 2.6 of the books.

> >>>> Because this is defined in appropriate technology binding specification
>as outlined in sections 2.5 and 2.6

> >>>> These are actually defined in the Service specifications (Common and
>Core). BUT they are not cast into concrete PDUs without the technology
>bindings.

> >>>> That is NOT true Peter, the information content and structure is
>COMPLETELY defined in the service specification BUT the on the wire
>representation is defined by the technology bindings.

> >>>> This is because it is completely left to the technology binding how to
>represent, for example, a Boolean. As it should be! As long as the fact that
>is it a Boolean and its value (TRUE) is communicated then applications on
>either side can interoperate.  Interoperability is only achieved, however, in
>conjunction with a common technology binding.

> >>>> This is because it is completely left to the technology binding.
>Implementors are given the freedom to choose an appropriate binding for their
>environment, but because the informational content HAS been standardised in
>the proposed Blue books there is complete informational interoperability,
>physical interoperability being provided by the transport technology
>bindings.

> >>>> Well they can if they do not follow the technology bindings. You point
>above however is a strong argument for these technology bindings to be Blue
>books (which we agree with you BTW) rather than Magenta as they are currently
>proposed to be.

> >>>> We are glad that you obviously completely understand the part that these
>standards provide. We are also glad that you understand that in isolation
>they do not provide the complete picture but that in conjunction with other
>(forthcoming) standards that complete picture is provided. It is a shame that
>you could not see immediately how this all fits together, but that may be
>easy for us to say as we have a full picture of our standards work and your
>set of fresh eyes have highlighted that this is less than obvious to
>newcomers.

> >>>> You are completely correct again Peter, but this is the job of the
>technology binding standards. Which, as you have stated before, would cast
>the abstract standards into indisputable, and therefore interoperable,
>concrete APIs.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cmc/attachments/20080611/e05fa6f0/attachment-0001.html