[Cesg-all] Results of CESG Polls closing 14 July 2017

[Thomas Gannett]

CESG E-Poll Identifier: CESG-P-2017-06-001 
Approval to release CCSDS 401.0-P-27.1, Radio 
Frequency and Modulation Systems—Part 1: Earth 
Stations and Spacecraft (Red/Pink Sheets, Issue 27.1) for CCSDS Agency review
Results of CESG poll beginning 30 June 2017 and ending 14 July 2017:

                  Abstain:  2 (33.33%) (Merri, Behal)
  Approve Unconditionally:  4 (66.67%) (Barkley, Shames, Burleigh, Moury)
  Approve with Conditions:  0 (0%)
  Disapprove with Comment:  0 (0%)

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

SOIS

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

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

CESG E-Poll Identifier: CESG-P-2017-06-002 
Approval to release CCSDS 522.0-R-1, Spacecraft 
Monitor and Control—Common Services (Red Book, Issue 1) for CCSDS Agency review
Results of CESG poll beginning 30 June 2017 and ending 14 July 2017:

                  Abstain:  1 (16.67%) (Calzolari)
  Approve Unconditionally:  1 (16.67%) (Behal)
  Approve with Conditions:  4 (66.67%) (Barkley, Merri, Shames, Burleigh)
  Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

Erik Barkley (Approve with Conditions): A 
condition and a general obervation/question.

Condition: The configuration services appears to 
be underspecified. In section 2.7.3, a use case 
of re-configurating a service provider is 
provided. there is an implication of tracking 
actual versus expected but this is really not 
borne out by the recommendation. For example, the 
notion of affected providers providing 
confirmation messages is indicated but where they 
fail to do so is not specified in the 
recommendation. What does the configuration 
service do in this case? As this is a service 
specification the behavior should be specified.



General Observation/Question (not a condition per 
se): why are state tables not provided in the 
recommendation? Or, service state diagrams? Use 
of state tables and state diagrams has ample 
precedent in defining service specifications. 
Adding state tables/diagrams will help to 
validate the recommendation and help make it more 
readily understandable to the reader/implementer 
and help ward off errors in implementation. 
Therefore a suggestion is to define service 
states and include the appropriate diagrams and/or tables.

Mario Merri (Approve with Conditions): For 
consistency please consider changing the title of 
the document from "Spacecraft Monitor and 
Control—Common Services" to "Mission 
Operations—Common Services" as indicated on CWE.

Peter Shames (Approve with Conditions): See 
attached PID form and PDF mark up. Too many issues to list individually.

Scott Burleigh (Approve with Conditions): This 
seems to be excellent work, but I don't see how 
it can be released as a draft Recommended 
Standard. According to section 6261 of the 
A02.1-Y-4 Procedures book, a document can be 
released as a Recommended Standard only after 
"two independent and interoperable prototypes or 
implementations ... have been developed and 
demonstrated in an operationally relevant 
environment". Because this specification relies 
wholly on the definitions of MAL and COM, which 
are abstract and therefore cannot be implemented, 
I don't see how two interoperable prototypes of 
this specification can ever be independently 
developed and demonstrated. I think this book is 
probably an excellent statement of *requirements* 
for a new Recommended Standard, hence an 
excellent Green Book. But I don't know how it can 
be released as a Red Book. My approval is conditional upon an explanation.

Gian Paolo Calzolari (Abstain): The terms in 
section 1.6 DEFINITION OF TERMS should be ordered 
alphabetically for reader's convenience.


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

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

CESG E-Poll Identifier: CESG-P-2017-06-003 
Approval to release CCSDS 522.2-R-1, Mission 
Operations—Mission Data Product Distribution 
Services (Red Book, Issue 1) for CCSDS Agency review
Results of CESG poll beginning 30 June 2017 and ending 14 July 2017:

                  Abstain:  1 (16.67%) (Calzolari)
  Approve Unconditionally:  2 (33.33%) (Merri, Behal)
  Approve with Conditions:  3 (50%) (Barkley, Shames, Burleigh)
  Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

Erik Barkley (Approve with Conditions): Two 
conditions, and a general observation, question.

1) Pg 2-2 , at the top, RE: "...The product type 
represents a category of mission data to which the product belongs
(e.g., parameter value evolution in a given time period, actions history)..."
How is a "parameter value evolution in a given 
time period.." a product type? I suspect the 
type, as in classification, that is being 
attempted here is engineering telemetry. If I 
think of controlling, via product type, I doubt 
I'd be selecting access control just for evething 
that is on a time-series basis -- rather I think 
it would be types of telemetry/particular 
instrument readings, etc. They all have a 
time-series nature, but that is not the 
fundamental type. Can a better example be provided?

2) Pg 2-7 states that the catalog entry is 
created and stored in the "COM Archive". Please 
include a mapping that ensures the "the product 
type, the product source", and the "product 
format" conform with COM Archive service needs 
(its not clear how this maps, to, for example, 
"area service", "object instance identifier", etc)



General observation/question (not a condition): 
in reviewing this, I could not but help to think 
about the fact that some CCSDS member space 
agencies already have various data distribution 
capabilities in place. For example, ESA has the 
Planetary Science Archive (PSA) and NASA has the 
Planetary Data System (PDS). To the best of my 
knowledge these organizations have already 
cooperated in developing standards related to 
distribution of various mission science products, 
particularly, through the IPDA (for example see 
https://planetarydata.org/standards/IPDA_PDAP_v1.0.pdf) 
I can't help but wonder with regard to this 
recommendation if in fact CCSDS is not 
overlapping with standards that have already been 
established. Perhaps there is a need for a 
liaison to be established? At the least, it seems 
that perhaps there could be supporting standards 
to this recommendation and therefore an overall stronger body of work.

Peter Shames (Approve with Conditions): This 
document is too immature to be esnt out for 
agency review.See attached PID form and document with mark-ups for details.

Scott Burleigh (Approve with Conditions): This 
seems to be excellent work, as best I can tell, 
but I don't see how I can in good conscience 
approve its release as a draft Recommended 
Standard. According to section 6261 of the 
A02.1-Y-4 Procedures book, a document can be 
released as a Recommended Standard only after 
"two independent and interoperable prototypes or 
implementations ... have been developed and 
demonstrated in an operationally relevant 
environment". Because this specification is 
entirely abstract, I don't see how two 
interoperable prototypes of the specification can 
ever be independently developed and demonstrated. 
I think this book is probably an excellent 
statement of *requirements* for a new Recommended 
Standard, hence an excellent Green Book. But I 
don't know how it can be released as a Red Book. 
My approval is conditional upon an explanation.


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

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

CESG E-Poll Identifier: CESG-P-2017-06-004 
Approval to release CCSDS 524.4-R-1, Mission 
Operations—Message Abstraction Layer Binding to 
ZMTP Transport (Red Book, Issue 1) for CCSDS Agency review
Results of CESG poll beginning 30 June 2017 and ending 14 July 2017:

                  Abstain:  1 (16.67%) (Calzolari)
  Approve Unconditionally:  2 (33.33%) (Merri, Behal)
  Approve with Conditions:  3 (50%) (Barkley, Shames, Burleigh)
  Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

Erik Barkley (Approve with Conditions): I do have 
a recommendation and a question. And it is my 
question that maybe a condition, depending upon 
further input from the WG. There may be a 
straightforward answer, but for now I am filing it as a condition.

My recmmendation is to provide some concrete 
examples in the form of an annex. There are many 
considerations in this mapping and I believe a 
fully worked example or two will help to provide 
validation and demonstrate same to the reader and eventual implementor.

My question is if there needs to be futher 
elobaration vis a vis the ZeroMQ message patterns 
and the MAL message patterns. I'm not sure that 
MAL message parameter mappings is sufficient. Its 
not entirely clear from my reading how MAL 
message patterns map, for example to ZeroMQ 
"PIPELINE" Pattern. I see some of the elements 
called out -- e.g., I see that a "DEALER" socket 
type is called out under certain conditions, but 
I don't see the overall pattern mapped out, and 
so therefore I am left to wonder if this really 
works as is or if there further restriction 
against "pure" ZMTP. (I also noted that the other 
ZMTP RFCs that define message patterns are in fact not referenced).

Finally, I have reviewed the SE AD's inputs and 
agree that they should be addressed.

Peter Shames (Approve with Conditions): This 
document is not yet at a sufficient level of 
maturity to be sent out to Agency Review. It has 
a number of technical issues and missing 
information. These are all covered in the 
attached marked-up copy of the document.

As specified it does not appear to be directly 
implementable for interoperability.

Scott Burleigh (Approve with Conditions): The 
term "Transport" is used in an ambiguous way in 
this document. ZMTP is referred to as a Transport 
Protocol in 1.2, but in 2.4.1 it is recognized 
that ZMTP relies on an underlying Transport Layer 
protocol such as TCP. The "Transport Layer" in 
figure 2.2 should be renamed something like 
"Message Exchange Layer" and this change should 
be propagated throughout the book. "Transport 
Layer" already means something; redefining it in 
this book would be a disservice to the reader.

Gian Paolo Calzolari (Abstain): The following 
Editorial corrections are required: remove from 
Annex F the acronyms AOS, BP, TM, TC because they are never used in the book.


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

* * * * * * * * * * * * * * * * * * * * * * * *
[PID forms and document markup are being forwarded to respective rapporteurs.]



Thomas Gannett
thomas.gannett at tgannett.net
+1 443 472 0805