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

[CCSDS Secretariat]

CESG E-Poll Identifier:  CESG-P-2010-06-002 Final approval of CCSDS 
872.0-M-1, Spacecraft Onboard Interface Services--Time Access Service 
(Magenta Book, Issue 1)
Results of CESG poll beginning 30 June 2010 and ending 19 July 2010:

                  Abstain:  0 (0%)
  Approve Unconditionally:  4 (66.67%) (Thompson, Taylor, Gerner, Moury)
  Approve with Conditions:  2 (33.33%) (Barkley, Durst)
  Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

      Erik Barkley (Approve with Conditions):  1) Section 1.1 
immediately discusses SOIS-compliant services as if the reader knows 
what SOIS is.  I believe best practice is to spell out acronyms upon 
first use.   Suggest spelling first use of acronym.  But also see 
below re SOIS acronym in this document in general.

2) Section 1.3 -- "vertical standaridsation" ?   Seems the rationale 
of promoting inter-interoperability between spacecraft integrators 
and equipment vendors is a sufficient  rationale?  Don't standards in 
general try to be "horizontal" by operating across many 
missions?  What is meant by "vertical" here?  Suggest re-phrasing.

3) To the best of my knowledge, I believe CCSDS documents are not 
include CCSDS internal organizational artifacts as part of their 
formal publication.  I do not recall other CCSDS documents prefixing 
a service identification with, as in this case, also the Area 
Identification.  Why is this the SOIS Time Access Service and not 
simply the Time Access Service?  The introduction (when fully spelled 
out) will make it clear that this is for spacecraft on board 
services.  Suggest replacing all instances of "SOIS Time Access 
Service" with "Time Access Service".  (Also, the document is not 
consistent about this -- in some places it calls out SOIS TAS, some 
places just TAS).

4) 1.5.2.3 definition of error bound: not clear what the addition of 
"notional" does to better convey the definition here?  Also, the term 
appears only in the introduction -- ie the practice makes no further 
reference to this term;  suggest removing it or (perhaps what was 
intended) add some linkage to where error data is returned.

5) 1.5.2.3 definition of time correlation: this is bit confusing -- 
the term is introduced but then practice goes on to say (on page 2-2) 
that time correlation is not in this practice;  perhaps the 
definition is not required?  Suggest removing the definition.

6) Section 2.3 -- Purpose and operation were a little confusing -- 
what is the difference between "fine-grain" vs. "coarse-grain" -- its 
seems that TAS is for "coarse-grain" only applications; is there some 
specification that can be offered as part of the practice to 
differentiate fine vs. coarse-grain?  E.g., are alarms delivered to 
within the nearest 1/100th second  fine or coarse-grain?  Or is there 
some other distinction?

7) Section 3.2 -- Not clear if the discussion about MIB is in 
relation to the underlying layers or is the TAS MIB.  It appears to 
be the TAS MIB?  Suggest making this explicit.

8) Alarms and Metronomes -- Should the practice recommend at least 
minimum capacities -- e.g.., relative to the class of mission 
presumably there is at least a minimum number of alarms and 
metronomes that need to be supported ? Should this be required in the 
MIB ?  (It seems to me that a robotic class mission with, e.g, 12 
instruments, might demand more from TAS than a mission with only 1 or 
2 instruments and a manned mission might be a very different situation).

      Bob Durst (Approve with Conditions):  This is not a condition 
for approval, but rather a comment (perhaps a lament) on the Time 
Access Service:  I struggle with why this isn't a Green Book.  There 
is only one service that is mandatory (wallclock time), and the 
abstract service interface bears so little resemblance to the 
concrete (and widely implemented) POSIX interface provided as an 
example, that I just don't see what utility this document provides as 
a magenta book.  The other two services are optional, and there's no 
meat in the MIB.  The one table that seems to actually be quite 
useful is a mapping of the SOIS Time Access Service onto the POSIX 
API.  Unfortunately, it is buried on page C-4 in an Informative 
Annex.  It's the ONLY thing in this document that actually seems to 
*recommend* a concrete *practice.*   (Indeed, it's the only place in 
the document where the word "recommend" is not boilerplate.)

Editorial:  The following sentence seems to be grammatically 
incorrect (from p. B-2):  "Depending on the sophistication of the 
local time source, it can detect missed correlation steps and can be 
configured such that the correlation operation never causes the 
indicated time to run backwards."  The first part of this sentence 
doesn't assert "sophistication," so the second half shouldn't assert 
capability.  If the first part of the sentence began "If the local 
time source is sufficiently sophisticated, ..." or the second half 
were made subjunctive (can->could in both places), I'd be more 
comfortable with the sentence.


Total Respondents:  6

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

      SEA

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

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