[Cesg-all] Results of CESG Polls closing 19 February 2020

Thu Feb 20 21:40:26 UTC 2020

CESG E-Poll Identifier:  CESG-P-2020-02-001 
Approval to publish CCSDS 313.0-Y-3, Space 
Assigned Numbers Authority (SANA)Role, 
Responsibilities, Policies, and Procedures Yellow Book, Issue 3)
Results of CESG poll beginning 4 February 2020 and ending 19 February 2020:

                 Abstain:  0 (0%) Approve 
Unconditionally:  3 (50%) (Shames, Burleigh, Wilmot)
Approve with Conditions:  3 (50%) (Barkley, Merri, Calzolari)
Disapprove with Comment:  0 (0%)
CONDITIONS/COMMENTS:

     Erik Barkley (Approve with Conditions):  1) 
General: Consider renaming SANA to give it a more 
accurately reflect its proper scope. SANA has 
long since outgrown such things spacecraft 
identifiers,  APIDs. We have such things as role 
definitions, contacts registry, XML schema 
registries,sites and apertures, quasar catalogs, 
celestial body reference frames, CCSDS glossary 
etc. all of which are more than just mere 
registration of numbers.  given that we have the 
sanaregistry.org URL etc. up and running it may 
be more trouble than it's worth to rename this. 
Alternatively, perhaps the document title could 
be revised (with any related scoping changes if 
needed) with an added indication in the document 
that for convience it is known simply SANA.
2) Re section 3.3:  I highly recommend that CMC 
adopt a high level data governance policy and 
that this section be revised when such a policy 
is well defined. Rationale: it seems to me that 
once SANA has achieved a certain "weight" or 
"size" (which it has),  summarily terminating 
SANA operations as indicated in the section could 
in fact be dangerous/ruinous.  (For example, does 
"killing" the quasar catalog adversly affect 
ongoing interferometry determiations -- I suspect 
it might - or is the CCSDS policy such that any 
data maintained by SANA shall never be "rated" as 
worthy for inter-agency operations? I don't think 
that is the current intention but this kind of 
thing, for example, has never been stated). Some 
sort of overall policy/high level principles for 
data governance for the CCSDS organization should 
be stated and the management of SANA operations 
brought in line with such a policy.  Such a high 
level policy should also address fitting with 
legal data protection considerations (e.g, the 
GPDR -- https://en.wikipedia.org/wiki/General_Data_Protection_Regulation).

     Mario Merri (Approve with Conditions):  1) 
Page 3-3 "NOTE  The CESG will not permit any 
standard specifying a registry to be sent for 
Agency review ...". It seems too me to strict a 
rule. I am sure that there will be situation 
where the CCSDS has an interest in publishing a 
book even if the associated registr(ies) is/are 
not finalised. Maybe the sentence could be 
modified to say ""NOTE  In general the CESG ..." 
and indicating that an AD who nevertheless 
approves the CESG poll needs to spell out why 
(s)he is content with a beta registry.

2) Page 3-5, Sec 3.10, last paragraph "The SANA 
Operator is responsible ...". See point 1 above.
3) Page 3-6 "the SANA shall send an email to 
cesg at mailman.ccsds.org to notify ...". I do not 
think this is necessary. CESG receives already too many emails.
4) Page 3-7 "The SANA Operator must not change 
the structure of any CCSDS registry without prior 
consent of the CESG or SSG ...". Not clear what 
CESG or SSG means. Is this "or" rather an "and"?

     Gian Paolo Calzolari (Approve with 
Conditions):  See attached pdf file with PIDs.
It is anticipated that some PIDs can require CESG wide discussion.

PS: The winword file is also attached for convenience.

     Jonathan Wilmot (Approve 
Unconditionally):   I agreed with many of the 
other conditions and just have two minor edits to add

1) ISection 3.11 "where is shall persist in 
Candidate" should be "where it shall persist in Candidate"

2) Section 3.12 the phrase "defined in the CCSDS 
Registry Management Policy" should have the actual book reference.

Total Respondents:  6

All Areas responded to this question.

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

* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier:  CESG-P-2020-02-002 
Approval to publish CCSDS 313.1-Y-2, CCSDS SANA 
Registry Management Policy Yellow Book, Issue 2)
Results of CESG poll beginning 4 February 2020 and ending 19 February 2020:

                 Abstain:  0 (0%) Approve 
Unconditionally:  3 (60%) (Shames, Burleigh, Wilmot)
Approve with Conditions:  2 (40%) (Barkley, Merri)
Disapprove with Comment:  0 (0%)
CONDITIONS/COMMENTS:

     Erik Barkley (Approve with Conditions):  1) 
In general, I believe CMC should state a clear 
data governance high level policy that is applicable to this yellow book.

2) Page 2-5, 2nd paragraph: I am unable to locate 
a "serivce catalog", "service access points" or 
"credential" new registries that exist on 
SANA.  Please provide the official SANA 
links/URLs or revise the text to indicate what really exists.

     Mario Merri (Approve with Conditions):  1) 
Page 1-2 If the document contains "Normative 
Text" shouldn't it be a blue book instead of a Yellow book?

2) It seems to me that there are several overlaps 
between this document and CCSDS 313.0-Y-3, Space 
Assigned Numbers Authority (SANA)Role, 
Responsibilities, Policies, and Procedures Yellow 
Book, for instance on pag 4-1 the SSG membership 
is spelled out which is also defined in 
313.0-Y-3. On top of making this document massive 
(70 pages), duplicated requirements will make 
maintenance a nightmare. Please identify all 
duplicated requirements and assign them only to a single book.

3) Page 4-2: The XML Expert Group has nothing to 
do with registry and it is not clear why it is 
here. In addition the membership makes reference 
to WGs: as we know, in CCSDS WGs are volatile and 
can be created and dismentaleld.

     Jonathan Wilmot (Approve 
Unconditionally):   Agree with other comment 
about duplication of material between CCSDS 
313.0-Y-3, Space Assigned Numbers Authority 
(SANA)Role, Responsibilities, Policies, and 
Procedure. Could one just reference the other as needed.

Total Respondents:  5

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

     SLS

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

* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier:  CESG-P-2020-02-003 
Approval to publish CCSDS 313.2-Y-2, Procedures 
for SANA Registry Specification Yellow Book, Issue 2)
Results of CESG poll beginning 4 February 2020 and ending 19 February 2020:

                 Abstain:  0 (0%) Approve 
Unconditionally:  3 (50%) (Shames, Burleigh, Wilmot)
Approve with Conditions:  3 (50%) (Barkley, Merri, Calzolari)
Disapprove with Comment:  0 (0%)
CONDITIONS/COMMENTS:

     Erik Barkley (Approve with Conditions):  1) 
Section 3.2.3 -- Does this need to be ammended to 
indicate inclusion of such evaluation in whatever 
subsequent request to SANA is issued? 2) Item 
3.2.6 reads "Any requirement for a registry 
referencing global data, SANA, 
Terminology/Glossary, XML, Uniform Resource Name 
(URN), or Object Identifier (OID) shall use or 
extend an existing global category 
registry".  This is confusing. What is meant by a 
regstiry referencing SANA?  By defintion is not a 
registry in SANA?  What is meant by a registry 
referencing Extensible Markup Language (XML) 
using or extending an existing global catagory 
registry?  XML is simply a languge and not a 
registry category?  Please rephrase this 
sentence   Also, note I don't think there is a 
URN registry (I have suggested that this be 
considered in the CCSDS URN document poll).

3) Item 3.2.13 -- use the term "body" rather 
"group" in the phrase "...any CCSDS group that 
acts..."  Rationale: avoid implication that only 
CCSDS working groups perform this function; a 
more inclusive term will help to make this more clear.

4) Item 3.2.14 -- please indicate how use of 
registry during prototype testing is to be 
documented.  What would be the success crietria for a test plan in this case?
5) Annex A -- is this really intended as 
Normative template? A1 indicates that these are 
examples.  As such replace "(NORMATIVE)" with "(INFORMATIVE)".
6) Annex A -- Strongly suggest putting 
the  instructional aspects of this annex  in 
italic font or in some other way offset from what 
is the body of text to be included verbatim from the example templates.

     Mario Merri (Approve with Conditions):  1) 
Page 1-1 If the document contains "Normative 
Text" shouldn't it be a blue book instead of a Yellow book?

2) I appreciate the desire to provide in a single 
book all what a WG needs to know. However, it 
seems to me that there are several overlaps 
between this document and CCSDS 313.0-Y-3, Space 
Assigned Numbers Authority (SANA)Role, 
Responsibilities, Policies, and Procedures Yellow 
Book. Duplicated requirements will make 
maintenance a nightmare. Please identify all 
duplicated requirements and assign them only to a single book.

     Gian Paolo Calzolari (Approve with 
Conditions):   See attached pdf file with PIDs.
It is anticipated that some PIDs can require CESG wide discussion.

PS: The winword file is also attached for convenience.

Total Respondents:  6

All Areas responded to this question.

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

* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier:  CESG-P-2020-02-004 
Approval to publish CCSDS 315.1-Y-1, CCSDS URN 
Namespace Policy (Yellow Book, Issue 1)
Results of CESG poll beginning 4 February 2020 and ending 19 February 2020:

                 Abstain:  0 (0%) Approve 
Unconditionally:  4 (66.67%) (Merri, Shames, Burleigh, Wilmot)
Approve with Conditions:  2 (33.33%) (Barkley, Calzolari)
Disapprove with Comment:  0 (0%)
CONDITIONS/COMMENTS:

     Erik Barkley (Approve with Conditions):   1) 
Section 3.2: <keyword> -- Please address 
registring <keyword>s with SANA. A request from 
SANA is indicated,  but no registry for URN 
related items is indicated. 2) Section 3.2 
<keyword> -- It may not necessarily be a CCSDS 
Working Group requesting a <keyword> value; 
modify text to indicate a CCSDS body, such as 
"The keyword is chosen by a  requesting CCSDS 
body such as a CCSDS working group" rather than " 
The keyword is chosen by the requesting CCSDS working group".
3) Document in general: following up from 1), 
does there need to be a SANA registry for all URN 
strings?  The book indicates URNs for documents, 
schemas, even SANA registries, but does not 
indicate registering the URN strings -- how are 
these to be tracked if not some sort of SANA 
registry for the URN strings?  Please address.
4) XML Expert Group -- Please clarify what this 
expert group's involvment is with management of 
URNs -- there does not appear to be any real role defined here.

     Gian Paolo Calzolari (Approve with 
Conditions):  See attached pdf file with PIDs.
It is anticipated that some PIDs can require CESG wide discussion.

PS: The winword file is also attached for convenience.

Total Respondents:  6

All Areas responded to this question.

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

* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier:  CESG-P-2020-02-005 
Approval to publish CCSDS 500.2-G-2, Navigation 
Data Messages Overview (Green Book, Issue 2)
Results of CESG poll beginning 4 February 2020 and ending 19 February 2020:

                 Abstain:  1 (16.67%) (Calzolari)
Approve Unconditionally:  5 (83.33%) (Barkley, Merri, Shames, Burleigh, Wilmot)
Approve with Conditions:  0 (0%) Disapprove with Comment:  0 (0%)
CONDITIONS/COMMENTS:

     Jonathan Wilmot (Approve 
Unconditionally):  Not a condition. The book 
references several schemmas for message exchange. 
The data types provided are not specific enough 
to exchange data. The data type "positiveInteger" 
has no size (64, 32, 16). Implementations require 
that information to interpret the message. The 
data types names are also different than other CCSDS schemas/books.

I say this to reinforce the need for "on the 
wire" message definitions to exchange data 
between systems with consistent types. This is 
part of a much wiider CESG discussion. This is a 
problen to be solved quickly for major international programs.

Total Respondents:  6

All Areas responded to this question.

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

* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier:  CESG-P-2020-02-006 
Approval to publish CCSDS 920.0-G-1, Cross 
Support Transfer Service Specification Framework Concept (Green Book, Issue 1)
Results of CESG poll beginning 4 February 2020 and ending 19 February 2020:

                 Abstain:  0 (0%) Approve 
Unconditionally:  4 (66.67%) (Barkley, Shames, Burleigh, Wilmot)
Approve with Conditions:  2 (33.33%) (Merri, Calzolari)
Disapprove with Comment:  0 (0%)
CONDITIONS/COMMENTS:

     Mario Merri (Approve with Conditions):  1) 
General: The CSS, and consequently the CSTS, 
deals with moving TM, TC and other auxiliary data 
between Ground Station and Control Centre. This 
is never mentioned in the document and these two 
terms (Ground Station and Control Centre) never 
appear once in the entire document. This is an 
important missing information in the Green Book, 
which leads to confused readers. As a minimum 
this should be explicitly and clearly expressed in the "Scope" section.

2) This is not a condition, just a comment: It is 
a pity to see re-confirmed that the CCSDS has 
developed 2 similar service frameworks (MO and CSTS).
     Peter Shames (Approve 
Unconditionally):   This document is in quite 
good shape, but it does contain a number of what 
I would characterize as editorial 
issues.  Examples of these are in the attached PID file.

     Gian Paolo Calzolari (Approve with Conditions):   See attached PIDs

Total Respondents:  6

All Areas responded to this question.

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

* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier:  CESG-P-2020-02-007 
Approval to publish CCSDS 660.2-G-2, XML 
Telemetric and Command Exchange (XTCE) (Green Book, Issue 2)
Results of CESG poll beginning 4 February 2020 and ending 19 February 2020:

                 Abstain:  0 (0%) Approve 
Unconditionally:  4 (80%) (Merri, Shames, Burleigh, Wilmot)
Approve with Conditions:  1 (20%) (Barkley)
Disapprove with Comment:  0 (0%)
CONDITIONS/COMMENTS:

     Erik Barkley (Approve with Conditions):   1) 
Why is the XTCE XML Schema not addressed in this 
book? A quick search shows that OMG has an .XSD 
file available for XTCE (see 
https://www.omg.org/spec/XTCE).  I think, even at 
the level of green book, such a refrence is useful to have.

Total Respondents:  5

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

     SLS

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

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