[Cesg-all] Results of CESG Polls closing 17 April 2020

Tue Apr 21 14:48:46 UTC 2020

CESG E-Poll Identifier:  CESG-P-2020-03-001 
Approval to publish CCSDS 371.0-G-1, Application 
and Support Layer Architecture (Green Book, Issue 1)
Results of CESG poll beginning 31 March 2020 and ending 17 April 2020:

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

CONDITIONS/COMMENTS:

     Erik Barkley (Approve with Conditions):   I 
am this close ("") to voting disapprove.  However 
I think CCSDS needs an a good architetural 
overview of the upper layers.  Unfortunately I 
find that there is still work to be 
done.  Several observations are listed below.

1) Page 1-3, section 1.4: suggest revising FROM 
"ASL Reference Architecture: describes the 
approach of describing the reference architecture 
in terms of seven modelling viewpoints and 
introduces the graphical notation used." TO "ASL 
Reference Architecture: defines the seven 
modeling viewpoints and the graphical notations 
used in this document" or something like that. 
RATIONALE: as currently written we essentially 
have the the reference architecture as describing 
the describing for the reference architecture; circular to say the least.

2) Page 2-1 Section 2 and onward -- a general 
finding throughout the remainder of the document: 
the question of architecture versus org chart 
figures prominently here as this seems to want to 
describe the architecture in terms of two CCSDS 
areas: SOIS and MOIMS. An immediate practical 
concern emerges in terms of considering document 
maintenance down the road. What happens if CCSDS 
is reorganized (and that has happened in the 
past) and the notion of areas and/or their names 
change? It may not be such a simple editing job 
of changing the names as some bits and pieces of 
functionality may move to an entirely different 
new organization in terms of working groups etc. 
It's a bit distressing that a more genuine 
approach to actually identifying the functions 
independent of the areas has not been pursued. 
Suggest revision to the document to anchor this 
firmly in functional terms rather than CCSDS area 
organizations. As a point of comparison, note 
that the Space Communications Cross 
Support--Architecture Description Document (CCSDS 
901.0-G-1) makes no mention any CCSDS 
Area.  Furthermore it has only one note with the 
term "Working Group" to indicate that WGs will produce future standards.
3) Page 2-1, Section 2.2.1 as follow-up from the 
immediately preceding observation the document 
talks about describing "...MOIMS interaction with 
the onboard environment..." -- Of course MOIMS 
has no interaction with anything in terms of an 
onboard spacecraft environment as it is an area 
in CCSDS with multiple working groups. I suspect 
the more functional aspect that is being 
attempted here is MO (mission operations).
4) Page 2-4, 2nd paragraph as yet further 
follow-up to the immediately two preceding 
observations I think that the phrase "based on 
CCSDS SLS SIS CSS and SEA standards" can be 
deleted. The protocol stack is already indicated 
as being defined in SCCS-ADD -- the areas 
producing the various standards involved are not 
really germane to description of the architecture.

5) Page 2-6, 1st paragraph: FROM "..Some 
platforms use Application Programming Interface 
(API) calls for communication with services. Some 
platforms use a software message bus for the same 
purpose. Some platforms are Time and Space 
Partitioned (TSP), with messages passed between 
partitions" TO -- something more technically 
correct.  RATIONALE: these two sentences are 
confusing and not technically correct. Any kind 
of software messaging bus comes with an API for 
sending the messages and/or receiving them from 
the message bus. How this differs from an "API 
for communication with services" is not at all made clear.

6) Page 2-9 A further follow up related to item 
2) above about focus on areas rather than 
functions.  In particular suggest revision to 
"But it is necessary to describe how the MOIMS 
services interface with the spacecraft 
environment..."  -- again MOIMS as an area; if 
you read expanding the acronym you get Mission 
Operation and Information Services services 
interface with the spacecraft environment..."  I 
suspect the real object is more just MO and not the entire area within CCSDS.

7) Page 3-1, 5th para:  FROM "MOIMS aspects" to 
"Mission Operations aspects" and FROM "SOIS 
aspects" to on board the spacecraft aspects"  -- 
again confusion of areas vs functionalities

8) Page 3-2, 2nd para: delete this 
paragraph.  Rationale: This has all been well 
established prior in the document.
9) Page 3-3, last para: FROM  "Two formulations 
of the Functional Viewpoint diagrams are 
provided. The standard diagram is 
function-oriented and shows functions connected 
by logical interfaces. These are contained in the 
body of the document. A set of alternative 
diagrams are contained in annex B and are 
service-oriented." TO something that is less 
confusion prone. RATIONALE: if the alternative 
diagrams contained in annex B are service 
oriented then why are they indicated as a 
formulation of the functional viewpoint diagram 
when in fact we have a service viewpoint as well?

10) Page 3-4, last para:  Please better clarify 
offline in "Such interactions may be supported as 
simple offline transfer of data, typically as a 
file transfer, or more complex online 
interactions between service consumer and 
provider functions."  RATIONALE: CFDP is a file 
transfer which I believe many people consider to be something that is "online".

11) Page 3-5, second to last bullet: Please 
clarify for "
 service interaction using message 
transfer;" -- does this include streaming applications?

12) Page 3-7 section 3.2, last paragraph in 
particular: this seems to argue that the 
implementation viewpoint is not really part of 
the architecture as it is essentially just examples. Please clarify.

13) Page 3-9, figure 3-2 (Graphical Notation for 
Functional Viewpoint Diagrams), Page 3-13, Figure 
3-5 (Graphical Graphical Notation for 
Communication Viewpoint Diagrams) , Page 3-15, 
Figure 3-7 (Graphical Notaion for Deployment 
Viewpoint Diagrams), Page 3-17, Figure 3-9 
(Graphical Notation for Implementation Viewpoint 
Process View -- by the way should not.B viewpoint 
diagrams and not viewpoint view?) all use the 
same color (a light value of yellow) to denote 
different things.  The Color Keys legend in 
Figure 3-1 does not address this.  In Figure 3-5, 
the communications view, functions are shown in a 
pinkish color.  In Figure 3-7, functions are 
shown with no distinct colors and are shown with 
the same light yellow color as the nodes. Figure 
3-6 (Graphical Notation for Physical Vuiewpoint 
Digrams), does by contrast, have a viewpoint 
specific color coding key.  Please provide and 
use consistently, viewpoint specific color coding 
keys.  Given that many of the same shapes show up 
in different viewpoint diagrams it be difficult 
if not confusing to quickly glean what is being addressd.
14) Page 4-3, Section 4.2.2.:  FROM "MOIMS AREA 
CONTEXT" TO "MO CONTEXT".  RATIONALE: MOIMS is 
part of the CCSDS organization and it's hard to 
see how Working Groups and Area Director/Deputy 
Area Director in fact participate in the 
operational concerns indicated in the diagram.

15) Page 4-3 Context diagram -- this type of 
diagram is not introduced in the reference 
architecture section. Please provide at least a 
note that this will be included in architectural 
viewpoints.  Perhaps the inetnation is that for 
each viewpoint there is an OV-1 type diagram? 
(https://en.wikipedia.org/wiki/Operational_View) ?

16) Page 4-45:  this seems to be a general 
discussion about two areas in CCSDS and security 
rather than any real architectural considerations 
with regard to security. Please revise to state 
the functions needed for the ASL security architecture.

17) Page 4-46: re observation 16, immediately 
above, what is stated as terms seem to be in fact 
the security functions needed.  Please consider revising accordingly.

18) Page 5-2: bottom third of page, page 5-3 top 
~quarter of page: Suggest either consistently 
ensuring all abbreviations are in the appropriate 
annex or consistently expanding them; as 
presented here it seems a bit haphazard as to why 
some abbreviations are spelled out in full while 
as others  are not.  There appears to be some 
sort of assumption that many of the abbreviations 
are widely understood while there are some new 
ones introduced here when in fact for reader 
coming across is the first time they're all essentially foreign.

19) General: the document gives an overall 
impression of providing viewpoints to describe an 
architecture into standards being developed 
within the MOIMS and SOIS areas.  That in and of 
itself is okay and of value. However the document 
purports to be an architecture description 
document. By the end of the document I had not 
seen anything that shows how the MO and On-Board 
functions were being arranged in architectural 
sense. For example,where is a diagram that shows 
the functional realtionship between device 
enumeration, not to mention Electronic Data Sheet 
and MO Monitor and Control? Presumably there 
would also be some sort of information kind of 
consideration in that the device enumeration/EDS 
would have some bearing on the parameters being 
configured for reporting monitor data. And 
presumably the on-board Time Access Service would 
have a bearing in this example as well.

20) Page 10-3, Section 10.2.3 -- this introduces 
an implementation view sub-view, "COMPONENT VIEW" 
this is not defined, identified in the reference 
arcthiectrue section. Consequently its not clear 
what the concerns are of this view point. Please 
address in the reference arcthiecture section.
21 Page 10-4 Section 10.2.4 -- Process view 
another view being introduced that is not defined 
in the reference arcitecture.  Same type of comment as 20 immediately above.

22) Section 3 -- general -- highly recommend that 
each of the viewpoint description sections begin 
by indicating the types of concerns/types of 
questions that the viewpoint is intended to 
address. I believe that checking the resulting 
descriptions/diagrams for each of the views will 
help to validate that the correct views have been 
developed. For example, the functional viewpoint 
begins the description that "
 The model is 
broken down hierarchically into a set of 
functions corresponding to recognizable areas of 
functionality within space systems which are 
often associated with particular type of 
information". But what are we trying to achieve 
with the functional view?  Identification of the 
functions that a mission needs for operating? 
Prioritization of the functions in terms of the 
need for standardization?  And to get to these 
types of questions I think the stakeholders need 
to be identified.  And presumably at the end of 
the day, the stakeholders would get into mission 
classes -- perhaps a set something like a list 
along the lines of Earth Observation, Navigation, 
Telecommunication / Relay. Astronomical / 
Astrophysical Observation, Space Platform 
Servicing. Solar System Body Observation / 
Orbiter / Flyby, Solar System Body 
Lander/Penetrator / In-situ Exploration, Sample 
return, Technology Demonstration.  It seems to me 
that one of the key stakeholders ultimately are 
the missions that would implement the standards 
and not having their concerns mapped out with 
respect to the architecture seems to me to be a 
disservice having invested the time to understand 
the architecture such as it's laid out.

     Gian Paolo Calzolari (Approve with 
Conditions):   SPP (Ref.[3]) is mentioned 3 times 
in the document. At least the first occurence 
should also mention EPP 133.1-B. For the second 
one, MOIMS should check/consider if SM&C allows using Encapsulation Packets.

     Jonathan Wilmot (Approve with 
Conditions):   SOIS area is in process of 
consolodating comments from NASA, CAST and ESA 
reveiwers and will provide those to SEA/Systems 
Architecture Working Group by 4/24/2020

Total Respondents:  5

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

     MOIMS

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-03-002 
Approval to publish CCSDS 133.1-B-3, 
Encapsulation Packet Protocol (Blue Book, Issue 3)
Results of CESG poll beginning 31 March 2020 and ending 17 April 2020:

                 Abstain:  0 (0%)
Approve Unconditionally:  5 (100%) (Barkley, 
Shames, Burleigh, Calzolari, Wilmot)
Approve with Conditions:  0 (0%)
Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

     Erik Barkley (Approve Unconditionally):   A 
minor clean up request -- Given that this is now 
going forward as the Encapsulation Packet 
Protocol, why is section 3 called "Service 
Definition" -- should this be "Protocol Definition" ?
     Jonathan Wilmot (Approve 
Unconditionally):  Remove repeated phrase on page 
16. "there are no timing relationships between 
the transfer of protocol data units supplied by 
the user and any data transmission mechanism within the Data Link Layer"

Total Respondents:  5

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

     MOIMS

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

* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier:  CESG-P-2020-03-003 
Approval to publish CCSDS 902.12-M-1, Cross 
Support Service ManagementCommon Data Entities (Magenta Book, Issue 1)
Results of CESG poll beginning 31 March 2020 and ending 17 April 2020:

                 Abstain:  1 (20%) (Calzolari)
Approve Unconditionally:  3 (60%) (Barkley, Burleigh, Wilmot)
Approve with Conditions:  1 (20%) (Shames)
Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

     Peter Shames (Approve with 
Conditions):   There are a few items identified 
in the markups to attached doc.  Most important 
being that the availablility of new Organization 
Roles in the relevant SANA registry are assumed, 
but they have not yet been created.  This doc, or 
some other, should create them.

Total Respondents:  5

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

     MOIMS

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-03-004 
Approval to publish CCSDS 902.13-M-1, Abstract 
Event Definition (Magenta Book, Issue 1)
Results of CESG poll beginning 31 March 2020 and ending 17 April 2020:

                 Abstain:  1 (20%) (Calzolari)
Approve Unconditionally:  3 (60%) (Barkley, Burleigh, Wilmot)
Approve with Conditions:  1 (20%) (Shames)
Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

     Peter Shames (Approve with Conditions):  The 
table 3-1 that defines the data structure appears 
to consist entirely of "optional" items, in which 
case a NULL structure would be acceptable.  Is 
this really the case?  Also, the terms "type" and 
"user" in that table appear to be so vaguely defined as to be meaningless.

Total Respondents:  5

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

     MOIMS

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

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