[CMC] CESG Poll Results - SOIS Documents

[Neil Dissinger]

CESG E-Poll Identifier: CESG-P-2007-05-001: Determination 
of Standards Track Selection of SOIS Draft Specifications	
Results of CESG poll beginning 24 May 2007 and ending 16 
May 2007:

    Recommended Standards (Blue): 3 (50%) (Peccia, Taylor, 
Gerner)
  Recommended Practice (Magenta): 1 (16.67%) (Barkley)
           Experimental (Orange): 2 (33.33%) (Shames, 
Durst)

CONDITIONS/COMMENTS:

      Peter Shames (Experimental (Orange)): These 
documents, at their present state of maturity and with 
their current content, do not meet the criteria for CCSDS 
Recommended Standards. A Reference Architecture document, 
when it is produced, would likely meet the criteria for a 
Magenta Book. These books provide a loose definition of an 
abstract service interface, but do not define it in either 
any concrete form nor in a form which can be translated 
into an interoperable implementation. In order to get 
these documents, which do represent a significant effort, 
out into the public view for broader scrutiny, I would 
recommend that they be distributed as CCSDS Orange Books.

      Nestor Peccia (Recommended Standards (Blue)): This 
discussion should be done at Agency level when reviewing 
the RBs as future recommended BBs.

It is better to decide the color "a posteriori" (if RIDs 
are generated accordingly), because the raised RIDs are 
consolidated / discussed / agreed at Agency level. A vote 
"a priori" (sometimes) includes the particular flavour / 
interest of ADs / DADs, and are irrelevant "vis-a-vis" the 
consolidated position of their Agency.

      Erik Barkley (Recommended Practice (Magenta)): As 
presently constituted, the set of books are close to a 
standards track (Blue books), and represent a very good 
start towards such. However, in my opinion, they are still 
too abstract to promote interoperability (for example, the 
datatype of a device identifier is not defined). I do not 
think they quite represent an experimental track so much 
as they represent a distillation of the types of services 
that occur for on board spacecraft systems. As presently 
constituted, the books strike me as detailed material most 
closely related to best practices. With further fleshing 
out toward more on-the-wire protocol definitions, etc., I 
will vote for Blue.

      Chris Taylor (Recommended Standards (Blue)): The 
present SOIS documents proposed for Agency review consist 
of a Green book which includes an overall architecture, 
derived communication services and a strategy for arriving 
at a set of accompanying protocols to be developed, in 
many cases, by external expert teams; together with a set 
of service definition Red books.

The strategy of releasing service specifications in 
advance of protocol specs may be unusual for CCSDS 
(although consistent with ISO which publishes service 
definitions independent of protocol specifications) and 
has been taken as the most effective and probably only 
practical way forward. For example, the subnetwork service 
definitions will be used in conjunction with different 
underlying data links each with its associated, and 
dedicated, protocol. The data link protocols will not be 
developed concurrently but all require a single service 
specification to be available. This is different to 
previous CCSDS recommendation where a service is supported 
by a single underlying protocol.

Another peculiarity of SOIS is the extremely broad scope 
of work that needs to tackled including, for example, Plug 
and play, an area that is still not fully investigated. 
Having an agreed framework available as a guide for 
further development will allow groups from divergent areas 
to harmonise their efforts and agree common as common way 
forward. This is already proving its validity with the 
announcement of the international SpaceWire working group 
to develop SOIS compliant protocols and the preparation of 
a CCSDS AMS subset as the protocol for the SOIS message 
exchange.

It is of course fully acknowledged that the final purpose 
of CCSDS Recommendations is to enable interoperability and 
without the specifications of protocols to support the 
present service definitions, this will not be achieved. 
The SOIS strategy to enable interoperability is a two step 
process: release of Green and Draft Red books to provide 
the solid platform necessary for protocol development and, 
once the protocols have been completed, propose them for 
adoption by the CCSDS as Blue Books.

As already stated in the SOIS plan of work, it is intended 
to hold the service definitions at a Draft Red book stage 
until protocol specification have been completed, 
including at least one data link protocol. It is not 
therefore proposed to request Blue status until associated 
protocols are available. It is, however, important that 
the draft Red books are released formally into the 
community to provide the necessary framework and CCSDS 
guidance and Agency level.

The SOIS area believes that the outlined approach is 
consistent with CCSDS procedures for a Blue Book track and 
furthermore has the necessary Agency support to proceed.



      Bob Durst (Experimental (Orange)): The SOIS 
documents have two potential goals: interoperability 
and/or application portability. Both of these, when the 
standards are complete, mature, and internationally agreed 
upon, should result in Blue Books. However, they are very 
different goals.

Interoperability (in the way that CCSDS views it) is the 
stated goal, and is established through protocol 
specifications. None of these documents have protocol 
specifications, however, and until they do they cannot be 
reviewed to determine whether they actually result in 
interoperability. At a point where protocol specifications 
become available, the degree of international consensus 
should be used to determine whether they are blue or 
orange.

Portability is another goal that is an important and 
useful target that could be addressed by the SOIS working 
groups and the service specifications that have been 
produced. But here, too, the "meat" is missing. A 
portability specification allows application portability 
across spacecraft and spacecraft operating systems (for 
example, the POSIX interface is a portability 
specification based on the Unix system interface, and 
allows applications to be ported across many different 
underlying hardware and operating system implementations). 
The thing that must be reviewed in a portability 
specification is the Application Programming Interface and 
Language Bindings for one or more programming languages. 
The service specifications that have been produced are an 
abstract representation of that interface, but until 
language bindings are produced, one cannot actually review 
the proposed standard to determine whether it will 
actually result in application portability.

So something is missing in either case: either a protocol 
specification or an API and at least one language binding. 
When SOIS decides (interoperability or portability -- 
although I believe that the default decision is 
interoperability), then it should produce the remainder of 
the specifications necessary for reviewers to determine 
whether the goal has been achieved. I provided what review 
comments that I could on the specifications as I received 
them. However, I cannot assess whether they will indeed 
promote international interoperability, because no 
protocol is specified.

As it stands, the SOIS documents are both incomplete and 
immature, so I believe that international consensus will 
be (or at least SHOULD be) difficult to achieve. Until 
each service specification is accompanied by a protocol 
specification, I don't believe that can or should be 
approved as a blue book, and I don't think that meaningful 
agency review is possible.


Total Respondents: 6

All Areas responded to this question.



SECRETARIAT INTERPRETATION OF RESULTS: Results are 
superseded by agreement
                                         to release 
service specifications as
                                         draft Recommended 
Practices.
PROPOSED SECRETARIAT ACTION: Initiate CMC poll for 
authorization
                                         to release of 
documents

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