[Cesg-all] Results of CESG Poll closing 28 February 2024

[CCSDS Secretariat]

CESG E-Poll Identifier:  CESG-P-2024-01-002 Approval to release CCSDS 508.0-P-1.1, Conjunction Data Message (Pink Book, Issue 1.1) for CCSDS Agency review

Results of CESG poll beginning 31 January 2024 and ending 28 February 2024:

                 Abstain:  0 (0%)  
 Approve Unconditionally:  5 (83.33%) (Barkley, Fischer, Cola, Aguilar Sanchez, Wilmot)
 Approve with Conditions:  1 (16.67%) (Shames)
 Disapprove with Comment:  0 (0%)  

CONDITIONS/COMMENTS:

     Peter Shames (Approve with Conditions):  The document has been improved, but it contains many vague references and fails to document the contents of many fields with sufficient precision to be useful.  Many of these terms may be well known within the possible circle of users, but this international standards should meet the usual BB tests.  It doesn't.

1) I would have just sent back the marked up copy, but the PDF is protected such that I could not even insert highlights or comments.  This is unacceptable.

2) Pg 1-4, Sec 1.5: There are no references to any SANA registries, at any point, yet there are several existing Nav and CCSDS Enterprise registries that should be identified and used.

3) Pg 3-2, Table 3-1: There is a note to the effect that "Originator" value "should be registered in SANA".  There is no such registry nor format specified, but there are "Organization" registries in SANA and "nav data provider" roles in SANA.  These should preferentially be used or perhaps you wish to adopt some specific "non-registered orginator" marking. 

4) Pg 3-2, Table 3-1: The same is true for "Message-For" which is intended to reference a Spacecraft.  There is a SANA Spaceraft registry that should preferentially be used.  Perhaps there are also some other "spacecraft" or "Object" registries that different communities prefer.  In that case I would recommend a new SANA registry of Spacecraft ID Sources be created and used and a way of marking which set of "Community" rules are being followed.

5) Pg 3-4, Table 3-3: There are no registries of "Object Designator", but it would appear that several exist and are implied but not named.  Provide a SANA registry for these and reference them in this table section.

 6) Pg 3-4, Table 3-3: There are no registries of "Catalog_Name", "Object_Name", "Object Type", or "Interntional Designator", but it would appear that several exist,  (or should). Sometimes example lists are provided, but these do not appear to be authoritative and are not unambiguously identified.  Provide SANA registries for these and reference them in this table section.  The same is true for many other fieldds in this table, like reference frame, gravity model, amtospheric model.  There should be registries for these and a simple, but effective, set of rules for updating these lists, as needed.

7) Pg B-1, Sec B1, Security:  The security section is extremely weak.  The topics of privacy, integrity, and authentication are mentioned, and then all responsibility is abdicated to other parts of the system supporting this kind of service.  It would be more responsive to at least identify the possibility of using existing CCSDS security standards, such as digital signatures (authentication), encryption (privacy), and hashes (integrity).  As in this case, so many of the references and identifiers in this standard are vague and unspecified that it might be fair to say that the only protection that is really offered is for the parties themselves to establish point-to-point trust relationships and use TBD means to secure the exchanges.  But the implication of the standard is that there should (will) be some authoritative sources of these CDMs.  I would think that these sources should be acknowledged.

8) Pg B-3, Sec B-2, SANA:  This section is totally inadequate.  There are several existing, Nav WG specific, SANA registries that should be specified, including several that contain relevant data, but none of these are identified.  And, based on earlier comments, it would appear that there are several new SANA registries, and the formal rules for updating them, that should be created.  Please add these references and define any new registries that are needed.  Given that this standard may be used by other entities that may not wish to use the SANA, some sort of "excape" mechanism should pshould be introduced robably be specified.  Maybe a new "Community" keyword that could distinguish CCSDS (using SANA) and "Agency XYZ" (using some other registry set of its own)?

     Jonathan Wilmot (Approve Unconditionally):  Many of the SANA xsd file links are broken. Please fix.


Example: https://nav.sanaregistry.org/r/ndmxml_unqualified/ndmx
ml-5.0.0-master-4.0.xsd"​


	


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

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