<span style=" font-size:12pt;font-family:Arial">Dear Peter,</span>
<br>
<br><span style=" font-size:12pt;font-family:Arial">unfortunately I was
not able to cast my approval as I was on leave. I had the opportunity now
to read the document, which I have found quite good. It is massive work
and 200+ pages so I am sure that a more careful analysis would have caught
some issues here and there, but the overall impression is solid.</span>
<br>
<br><span style=" font-size:12pt;font-family:Arial">Sorry for having missed
the poll.</span>
<br>
<br><span style=" font-size:12pt;font-family:Arial">Regards,</span>
<br>
<br><span style=" font-size:12pt;font-family:Arial">__Mario</span>
<br><span style=" font-size:9pt;color:#800080;font-family:sans-serif">-----
Forwarded by Mario Merri/esoc/ESA on 23/04/2020 18:34 -----</span>
<br>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">"CCSDS
Secretariat" <thomas.gannett@tgannett.net></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">cesg-all@mailman.ccsds.org</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style=" font-size:9pt;font-family:sans-serif">21/04/2020
16:49</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">[Cesg-all]
Results of CESG Polls closing 17 April 2020</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Sent
by: </span><span style=" font-size:9pt;font-family:sans-serif">"CESG-All"
<cesg-all-bounces@mailman.ccsds.org></span>
<br>
<hr noshade>
<br>
<br>
<br><tt><span style=" font-size:10pt">CESG E-Poll Identifier: CESG-P-2020-03-001
<br>
Approval to publish CCSDS 371.0-G-1, Application <br>
and Support Layer Architecture (Green Book, Issue 1)<br>
Results of CESG poll beginning 31 March 2020 and ending 17 April 2020:<br>
<br>
Abstain: 0
(0%)<br>
Approve Unconditionally: 2 (40%) (Shames, Burleigh)<br>
Approve with Conditions: 3 (60%) (Barkley, Calzolari, Wilmot)<br>
Disapprove with Comment: 0 (0%)<br>
<br>
CONDITIONS/COMMENTS:<br>
<br>
Erik Barkley (Approve with Conditions): I <br>
am this close ("") to voting disapprove. However <br>
I think CCSDS needs an a good architetural <br>
overview of the upper layers. Unfortunately I <br>
find that there is still work to be <br>
done. Several observations are listed below.<br>
<br>
<br>
1) Page 1-3, section 1.4: suggest revising FROM <br>
"ASL Reference Architecture: describes the <br>
approach of describing the reference architecture <br>
in terms of seven modelling viewpoints and <br>
introduces the graphical notation used." TO "ASL <br>
Reference Architecture: defines the seven <br>
modeling viewpoints and the graphical notations <br>
used in this document" or something like that. <br>
RATIONALE: as currently written we essentially <br>
have the the reference architecture as describing <br>
the describing for the reference architecture; circular to say the least.<br>
<br>
2) Page 2-1 Section 2 and onward -- a general <br>
finding throughout the remainder of the document: <br>
the question of architecture versus org chart <br>
figures prominently here as this seems to want to <br>
describe the architecture in terms of two CCSDS <br>
areas: SOIS and MOIMS. An immediate practical <br>
concern emerges in terms of considering document <br>
maintenance down the road. What happens if CCSDS <br>
is reorganized (and that has happened in the <br>
past) and the notion of areas and/or their names <br>
change? It may not be such a simple editing job <br>
of changing the names as some bits and pieces of <br>
functionality may move to an entirely different <br>
new organization in terms of working groups etc. <br>
It's a bit distressing that a more genuine <br>
approach to actually identifying the functions <br>
independent of the areas has not been pursued. <br>
Suggest revision to the document to anchor this <br>
firmly in functional terms rather than CCSDS area <br>
organizations. As a point of comparison, note <br>
that the Space Communications Cross <br>
Support--Architecture Description Document (CCSDS <br>
901.0-G-1) makes no mention any CCSDS <br>
Area. Furthermore it has only one note with the <br>
term "Working Group" to indicate that WGs will produce future
standards.<br>
3) Page 2-1, Section 2.2.1 as follow-up from the <br>
immediately preceding observation the document <br>
talks about describing "...MOIMS interaction with <br>
the onboard environment..." -- Of course MOIMS <br>
has no interaction with anything in terms of an <br>
onboard spacecraft environment as it is an area <br>
in CCSDS with multiple working groups. I suspect <br>
the more functional aspect that is being <br>
attempted here is MO (mission operations).<br>
4) Page 2-4, 2nd paragraph as yet further <br>
follow-up to the immediately two preceding <br>
observations I think that the phrase "based on <br>
CCSDS SLS SIS CSS and SEA standards" can be <br>
deleted. The protocol stack is already indicated <br>
as being defined in SCCS-ADD -- the areas <br>
producing the various standards involved are not <br>
really germane to description of the architecture.<br>
<br>
5) Page 2-6, 1st paragraph: FROM "..Some <br>
platforms use Application Programming Interface <br>
(API) calls for communication with services. Some <br>
platforms use a software message bus for the same <br>
purpose. Some platforms are Time and Space <br>
Partitioned (TSP), with messages passed between <br>
partitions" TO -- something more technically <br>
correct. RATIONALE: these two sentences are <br>
confusing and not technically correct. Any kind <br>
of software messaging bus comes with an API for <br>
sending the messages and/or receiving them from <br>
the message bus. How this differs from an "API <br>
for communication with services" is not at all made clear.<br>
<br>
6) Page 2-9 A further follow up related to item <br>
2) above about focus on areas rather than <br>
functions. In particular suggest revision to <br>
"But it is necessary to describe how the MOIMS <br>
services interface with the spacecraft <br>
environment..." -- again MOIMS as an area; if <br>
you read expanding the acronym you get Mission <br>
Operation and Information Services services <br>
interface with the spacecraft environment..." I <br>
suspect the real object is more just MO and not the entire area within
CCSDS.<br>
<br>
7) Page 3-1, 5th para: FROM "MOIMS aspects" to <br>
"Mission Operations aspects" and FROM "SOIS <br>
aspects" to on board the spacecraft aspects" -- <br>
again confusion of areas vs functionalities<br>
<br>
8) Page 3-2, 2nd para: delete this <br>
paragraph. Rationale: This has all been well <br>
established prior in the document.<br>
9) Page 3-3, last para: FROM "Two formulations <br>
of the Functional Viewpoint diagrams are <br>
provided. The standard diagram is <br>
function-oriented and shows functions connected <br>
by logical interfaces. These are contained in the <br>
body of the document. A set of alternative <br>
diagrams are contained in annex B and are <br>
service-oriented." TO something that is less <br>
confusion prone. RATIONALE: if the alternative <br>
diagrams contained in annex B are service <br>
oriented then why are they indicated as a <br>
formulation of the functional viewpoint diagram <br>
when in fact we have a service viewpoint as well?<br>
<br>
10) Page 3-4, last para: Please better clarify <br>
offline in "Such interactions may be supported as <br>
simple offline transfer of data, typically as a <br>
file transfer, or more complex online <br>
interactions between service consumer and <br>
provider functions." RATIONALE: CFDP is a file <br>
transfer which I believe many people consider to be something that is "online".<br>
<br>
11) Page 3-5, second to last bullet: Please <br>
clarify for "… service interaction using message <br>
transfer;" -- does this include streaming applications?<br>
<br>
12) Page 3-7 section 3.2, last paragraph in <br>
particular: this seems to argue that the <br>
implementation viewpoint is not really part of <br>
the architecture as it is essentially just examples. Please clarify.<br>
<br>
13) Page 3-9, figure 3-2 (Graphical Notation for <br>
Functional Viewpoint Diagrams), Page 3-13, Figure <br>
3-5 (Graphical Graphical Notation for <br>
Communication Viewpoint Diagrams) , Page 3-15, <br>
Figure 3-7 (Graphical Notaion for Deployment <br>
Viewpoint Diagrams), Page 3-17, Figure 3-9 <br>
(Graphical Notation for Implementation Viewpoint <br>
Process View -- by the way should not.B viewpoint <br>
diagrams and not viewpoint view?) all use the <br>
same color (a light value of yellow) to denote <br>
different things. The Color Keys legend in <br>
Figure 3-1 does not address this. In Figure 3-5, <br>
the communications view, functions are shown in a <br>
pinkish color. In Figure 3-7, functions are <br>
shown with no distinct colors and are shown with <br>
the same light yellow color as the nodes. Figure <br>
3-6 (Graphical Notation for Physical Vuiewpoint <br>
Digrams), does by contrast, have a viewpoint <br>
specific color coding key. Please provide and <br>
use consistently, viewpoint specific color coding <br>
keys. Given that many of the same shapes show up <br>
in different viewpoint diagrams it be difficult <br>
if not confusing to quickly glean what is being addressd.<br>
14) Page 4-3, Section 4.2.2.: FROM "MOIMS AREA <br>
CONTEXT" TO "MO CONTEXT". RATIONALE: MOIMS is <br>
part of the CCSDS organization and it's hard to <br>
see how Working Groups and Area Director/Deputy <br>
Area Director in fact participate in the <br>
operational concerns indicated in the diagram.<br>
<br>
15) Page 4-3 Context diagram -- this type of <br>
diagram is not introduced in the reference <br>
architecture section. Please provide at least a <br>
note that this will be included in architectural <br>
viewpoints. Perhaps the inetnation is that for <br>
each viewpoint there is an OV-1 type diagram? <br>
(</span></tt><a href=https://en.wikipedia.org/wiki/Operational_View><tt><span style=" font-size:10pt">https://en.wikipedia.org/wiki/Operational_View</span></tt></a><tt><span style=" font-size:10pt">)
?<br>
<br>
16) Page 4-45: this seems to be a general <br>
discussion about two areas in CCSDS and security <br>
rather than any real architectural considerations <br>
with regard to security. Please revise to state <br>
the functions needed for the ASL security architecture.<br>
<br>
17) Page 4-46: re observation 16, immediately <br>
above, what is stated as terms seem to be in fact <br>
the security functions needed. Please consider revising accordingly.<br>
<br>
18) Page 5-2: bottom third of page, page 5-3 top <br>
~quarter of page: Suggest either consistently <br>
ensuring all abbreviations are in the appropriate <br>
annex or consistently expanding them; as <br>
presented here it seems a bit haphazard as to why <br>
some abbreviations are spelled out in full while <br>
as others are not. There appears to be some <br>
sort of assumption that many of the abbreviations <br>
are widely understood while there are some new <br>
ones introduced here when in fact for reader <br>
coming across is the first time they're all essentially foreign.<br>
<br>
19) General: the document gives an overall <br>
impression of providing viewpoints to describe an <br>
architecture into standards being developed <br>
within the MOIMS and SOIS areas. That in and of <br>
itself is okay and of value. However the document <br>
purports to be an architecture description <br>
document. By the end of the document I had not <br>
seen anything that shows how the MO and On-Board <br>
functions were being arranged in architectural <br>
sense. For example,where is a diagram that shows <br>
the functional realtionship between device <br>
enumeration, not to mention Electronic Data Sheet <br>
and MO Monitor and Control? Presumably there <br>
would also be some sort of information kind of <br>
consideration in that the device enumeration/EDS <br>
would have some bearing on the parameters being <br>
configured for reporting monitor data. And <br>
presumably the on-board Time Access Service would <br>
have a bearing in this example as well.<br>
<br>
20) Page 10-3, Section 10.2.3 -- this introduces <br>
an implementation view sub-view, "COMPONENT VIEW" <br>
this is not defined, identified in the reference <br>
arcthiectrue section. Consequently its not clear <br>
what the concerns are of this view point. Please <br>
address in the reference arcthiecture section.<br>
21 Page 10-4 Section 10.2.4 -- Process view <br>
another view being introduced that is not defined <br>
in the reference arcitecture. Same type of comment as 20 immediately
above.<br>
<br>
22) Section 3 -- general -- highly recommend that <br>
each of the viewpoint description sections begin <br>
by indicating the types of concerns/types of <br>
questions that the viewpoint is intended to <br>
address. I believe that checking the resulting <br>
descriptions/diagrams for each of the views will <br>
help to validate that the correct views have been <br>
developed. For example, the functional viewpoint <br>
begins the description that "… The model is <br>
broken down hierarchically into a set of <br>
functions corresponding to recognizable areas of <br>
functionality within space systems which are <br>
often associated with particular type of <br>
information". But what are we trying to achieve <br>
with the functional view? Identification of the <br>
functions that a mission needs for operating? <br>
Prioritization of the functions in terms of the <br>
need for standardization? And to get to these <br>
types of questions I think the stakeholders need <br>
to be identified. And presumably at the end of <br>
the day, the stakeholders would get into mission <br>
classes -- perhaps a set something like a list <br>
along the lines of Earth Observation, Navigation, <br>
Telecommunication / Relay. Astronomical / <br>
Astrophysical Observation, Space Platform <br>
Servicing. Solar System Body Observation / <br>
Orbiter / Flyby, Solar System Body <br>
Lander/Penetrator / In-situ Exploration, Sample <br>
return, Technology Demonstration. It seems to me <br>
that one of the key stakeholders ultimately are <br>
the missions that would implement the standards <br>
and not having their concerns mapped out with <br>
respect to the architecture seems to me to be a <br>
disservice having invested the time to understand <br>
the architecture such as it's laid out.<br>
<br>
Gian Paolo Calzolari (Approve with <br>
Conditions): SPP (Ref.[3]) is mentioned 3 times <br>
in the document. At least the first occurence <br>
should also mention EPP 133.1-B. For the second <br>
one, MOIMS should check/consider if SM&C allows using Encapsulation
Packets.<br>
<br>
Jonathan Wilmot (Approve with <br>
Conditions): SOIS area is in process of <br>
consolodating comments from NASA, CAST and ESA <br>
reveiwers and will provide those to SEA/Systems <br>
Architecture Working Group by 4/24/2020<br>
<br>
<br>
Total Respondents: 5<br>
<br>
No response was received from the following Area(s):<br>
<br>
MOIMS<br>
<br>
<br>
<br>
SECRETARIAT INTERPRETATION OF RESULTS: Approved with Conditions<br>
PROPOSED SECRETARIAT ACTION: Generate
<br>
CMC poll after conditions have been addressed<br>
<br>
* * * * * * * * * * * * * * * * * * * * * * * *<br>
CESG E-Poll Identifier: CESG-P-2020-03-002 <br>
Approval to publish CCSDS 133.1-B-3, <br>
Encapsulation Packet Protocol (Blue Book, Issue 3)<br>
Results of CESG poll beginning 31 March 2020 and ending 17 April 2020:<br>
<br>
Abstain: 0
(0%)<br>
Approve Unconditionally: 5 (100%) (Barkley, <br>
Shames, Burleigh, Calzolari, Wilmot)<br>
Approve with Conditions: 0 (0%)<br>
Disapprove with Comment: 0 (0%)<br>
<br>
CONDITIONS/COMMENTS:<br>
<br>
Erik Barkley (Approve Unconditionally): A <br>
minor clean up request -- Given that this is now <br>
going forward as the Encapsulation Packet <br>
Protocol, why is section 3 called "Service <br>
Definition" -- should this be "Protocol Definition" ?<br>
Jonathan Wilmot (Approve <br>
Unconditionally): Remove repeated phrase on page <br>
16. "there are no timing relationships between <br>
the transfer of protocol data units supplied by <br>
the user and any data transmission mechanism within the Data Link Layer"<br>
<br>
<br>
Total Respondents: 5<br>
<br>
No response was received from the following Area(s):<br>
<br>
MOIMS<br>
<br>
<br>
<br>
SECRETARIAT INTERPRETATION OF RESULTS: Approved Unconditionally<br>
PROPOSED SECRETARIAT ACTION: Generate
CMC poll<br>
<br>
* * * * * * * * * * * * * * * * * * * * * * * *<br>
CESG E-Poll Identifier: CESG-P-2020-03-003 <br>
Approval to publish CCSDS 902.12-M-1, Cross <br>
Support Service Management—Common Data Entities (Magenta Book, Issue 1)<br>
Results of CESG poll beginning 31 March 2020 and ending 17 April 2020:<br>
<br>
Abstain: 1
(20%) (Calzolari)<br>
Approve Unconditionally: 3 (60%) (Barkley, Burleigh, Wilmot)<br>
Approve with Conditions: 1 (20%) (Shames)<br>
Disapprove with Comment: 0 (0%)<br>
<br>
CONDITIONS/COMMENTS:<br>
<br>
Peter Shames (Approve with <br>
Conditions): There are a few items identified <br>
in the markups to attached doc. Most important <br>
being that the availablility of new Organization <br>
Roles in the relevant SANA registry are assumed, <br>
but they have not yet been created. This doc, or <br>
some other, should create them.<br>
<br>
<br>
Total Respondents: 5<br>
<br>
No response was received from the following Area(s):<br>
<br>
MOIMS<br>
<br>
<br>
<br>
SECRETARIAT INTERPRETATION OF RESULTS: Approved with Conditions<br>
PROPOSED SECRETARIAT ACTION: Generate
<br>
CMC poll after conditions have been addressed<br>
<br>
* * * * * * * * * * * * * * * * * * * * * * * *<br>
CESG E-Poll Identifier: CESG-P-2020-03-004 <br>
Approval to publish CCSDS 902.13-M-1, Abstract <br>
Event Definition (Magenta Book, Issue 1)<br>
Results of CESG poll beginning 31 March 2020 and ending 17 April 2020:<br>
<br>
Abstain: 1
(20%) (Calzolari)<br>
Approve Unconditionally: 3 (60%) (Barkley, Burleigh, Wilmot)<br>
Approve with Conditions: 1 (20%) (Shames)<br>
Disapprove with Comment: 0 (0%)<br>
<br>
CONDITIONS/COMMENTS:<br>
<br>
Peter Shames (Approve with Conditions): The <br>
table 3-1 that defines the data structure appears <br>
to consist entirely of "optional" items, in which <br>
case a NULL structure would be acceptable. Is <br>
this really the case? Also, the terms "type" and <br>
"user" in that table appear to be so vaguely defined as to be
meaningless.<br>
<br>
<br>
Total Respondents: 5<br>
<br>
No response was received from the following Area(s):<br>
<br>
MOIMS<br>
<br>
<br>
<br>
SECRETARIAT INTERPRETATION OF RESULTS: Approved with Conditions<br>
PROPOSED SECRETARIAT ACTION: Generate
<br>
CMC poll after conditions have been addressed<br>
<br>
* * * * * * * * * * * * * * * * * * * * * * * *<br>
<br>
_______________________________________________<br>
CESG-All mailing list<br>
CESG-All@mailman.ccsds.org<br>
</span></tt><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg-all"><tt><span style=" font-size:10pt">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg-all</span></tt></a><tt><span style=" font-size:10pt"><br>
</span></tt>
<br><PRE>This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@esa.int).
</PRE>