[Cesg-all] Results of CESG Polls closing 19 November 2024

[CCSDS Secretariat]

CESG E-Poll Identifier:  CESG-P-2024-10-003 Approval to publish CCSDS 131.5-O-1 Cor. 1, Technical Corrigendum  to CCSDS 131.5-O-1, Issued November 2014

Results of CESG poll beginning 29 October 2024 and ending 19 November 2024:

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

Total Respondents:  5

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-2024-10-004 Approval to release CCSDS 506.1-P-1.1, Delta-DOR Raw Data Exchange Format (Pink Book, Issue 1.1) for CCSDS Agency review

Results of CESG poll beginning 29 October 2024 and ending 19 November 2024:

                 Abstain:  0 (0%)  
 Approve Unconditionally:  4 (80%) (Barkley, Fischer, Shames, Aguilar Sanchez)
 Approve with Conditions:  1 (20%) (Cola)
 Disapprove with Comment:  0 (0%)  

CONDITIONS/COMMENTS:

     Erik Barkley (Approve Unconditionally):  Note -- this is not a condition for proceeding to agency review, but consider this a RID for agency review: regarding the DELTA-DOR ORGANIZATION, DELTA-DOR SPACECRAFT, DELTA-DOR APERTURES registries, I suggest adding, to B2.1, a note to the effect that the corresponding item in the corresponding Enterprise class registry is added prior to the local DELTA-DOR xxxx type registry.  Rationale: there are mandatory OIDs into the Entrprise class registires called out in the local DELTA-DOR xxxx registries. [E.g., "...Required fields: 
– Aperture alias (four-alphanumeric-character aperture alias); 
– OID in reference [11]...." in B2.3]

For more information on CCSDS Enterprise Class registries  see CCSDS 313.1-Y-2, section 2.4.

     Tomaso de Cola (Approve with Conditions):  Just a minor comment, the in Section 6, the file naming convention expresses the year as YY, whereas other attributes (e.g., START_TIME, END_TIME) express it as YYYY. Is there any reason for this difference and can it be problematic?


Total Respondents:  5

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-2024-10-005 Approval to publish CCSDS 311.0-M-2, Reference Architecture for Space Data Systems (Magenta Book, Issue 2)

Results of CESG poll beginning 29 October 2024 and ending 19 November 2024:

                 Abstain:  0 (0%)  
 Approve Unconditionally:  2 (50%) (Shames, Cola)
 Approve with Conditions:  2 (50%) (Barkley, Aguilar Sanchez)
 Disapprove with Comment:  0 (0%)  

CONDITIONS/COMMENTS:

     Erik Barkley (Approve with Conditions):  1.	Section 1.3, re the text  "...can, and have, been directly adopted for use with the UML and SysML representations that are provided by typical Model Based Systems Engineering (MBSE) tools" can references regarding the "directly adopted for use" be provided? Perhaps as a footnote? 

2.	Figure 2-4 -- can this be cleaned up?  At least get the text to fit in the boxes (Metamodel, Environment), and not have the arrows slice through the text (e.g. it says "Offers" from Function to Service but it is not really clear). It should be possible to move the text or arrows sufficiently so that all is clear. 

3.	Figure 2-4 -- what is meant by "prop" in Component Node, Connector (Link)? 

4.	Figure 3-1 -- Are the textual element for the "Logical Link between Elements" required for this icon?  (these are "Service Consumer, Data, Service Provider") -- it seems this is an example application of the icon, not the icon "definition"?  I will note that the box with "Data" tends to make sense as part of the icon definition. Perhaps "Service Consumer" and "Service Provider" should read Object A and Object B? 

5.	Figure 3-4 -- consider changing the term "Main Object” to just simply  " Object".  rationale:  this more readily supports the composition of an object by other objects as opposed to a composition of a  main object by other main objects and I think is more in line with what the diagram is showing. (Does RASDS distinguish between "main object” and "object"?) I think the change will make this figure more consistent with Figure 6-2 (which does not have a "main component", but just components)

6.	Figure 4-6 -- could use some cleaning (reference comment on figure 2-4 -- also, the little cartoon figures with thought and speech bubbles -- are these part of RASDS? If not does RASDS recommend these kinds of embellishments?  ( to be clear, they do help, but I'm just trying to sort out what is actually RASDS versus what is not) 

7.	Annex C-- I am not sure  that this add anything very useful.  Reading through it, it appears more to be a tutorial on SYSML than  actually showing anything on RASDS.   Perhaps what could make this more useful is to show the RASDS equivalent for the SYSML diagrams shown . Presumably the RASDS diagrams would be more succinct? As is, I  don't really see that this adds anything to elucidate or otherwise define RASDS -- perhaps remove?

I also noted an 8th point:

8.	Figure C-4 – comments/TODO list regarding review with Mike Anderson may not be the most appropriate for a formal CCSDS document publication?


     Ignacio Aguilar Sanchez (Approve with Conditions):  ​After a more detailed reading of the document, I am revising my vote. There are a few points that in my opinion would need to be addressed before publication.

1. In section 1.4, page 1-3, three additional viewpoints are introduced with respect to the previous version of the document. SInce the more viewpoints, the more complex the architecture description, it is in my view crucial to explain why additional viewpoints are needed. In this respect, it is stated that they are there to support the needs of ISO TC20/SC14. A search for related definitions in ISO OBP indicated that only the Physical Viewpoint is defined by ISO, which begs the question about the origin of the other two viewpoints (Services, Operational). Where are they coming from?

2. In section 2.3.2, the derivation of the Connectivity and Structural Viewpoints from the new Physical Viewpoint is introduced. However, it is not explained why they were needed.

​3. The current definition of "viewpoint" in 3.2.5, page 3-5 is recursive, citing the term to be defined in the definition. A search on ISO OBP, even filtering for the relevant technical domain, provided way too many hits to be able to propose a solid definition. In some of those hits, the "architecture viewpoint" is equated to "viewpoint".


Total Respondents:  4

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

     MOIMS
     SOIS



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

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