<br><font size=1 color=#800080 face="sans-serif">----- Forwarded by Nestor
Peccia/esoc/ESA on 29/07/2009 08:54 -----</font>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>CCSDS Secretariat <tomg@aiaa.org></b>
</font>
<br><font size=1 face="sans-serif">Sent by: cesg-bounces@mailman.ccsds.org</font>
<p><font size=1 face="sans-serif">28/07/2009 23:31</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">cesg@mailman.ccsds.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">[CESG] Results of CESG polls closing
27 July 2009</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=3>CESG E-Poll Identifier: CESG-P-2009-07-001 Approval
of update to CCSDS 520.0-G-2, Mission Operations Services Concept<br>
Results of CESG poll beginning 6 July 2009 and ending 27 July 2009:<br>
<br>
Abstain: 2
(33.33%) (Taylor, Gerner)<br>
Approve Unconditionally: 1 (16.67%) (Moury)<br>
Approve with Conditions: 2 (33.33%) (Barkley, Durst)<br>
Disapprove with Comment: 1 (16.67%) (Shames)<br>
<br>
CONDITIONS/COMMENTS:<br>
<br>
Peter Shames (Disapprove with Comment): Here is my
analysis of this revised MOIMS SM&C (Mission Operations Services) document.
There are MANY mark-ups in the attached text. My summary of key issues
are these:<br>
<br>
Major issues:<br>
- Unresolved overlaps with other WGs (CSS (SM, CSTS), MOIMS (Nav, IPR),
SEA (IA, Reg/Rep), SIS (CFDP, AMS), SOIS (message transfer service))<br>
- Assertions about what is needed to make a real "Blue Book",
i.e. both the MAL and a technology mapping, taken together.<br>
- Confusing descriptions of different MOS services (planning, scheduling,
automation)<br>
- Lack of clarity of relationship between use of MAL and “technology bindings”
for interoperability versus "service specific encodings"<br>
- Use of "SOA" terminology without adequate explanation or relationship
to precedent related CCSDS work<br>
<br>
The first issue of overlaps with other CCSDS WGs is a big one, and we keep
returning to it over and over. This is largely because the stated
scope of SM&C is so broad, at an applications layer, but that it reaches
down into other layers for “interoperability”. This fact,
coupled with an on-going disregard for (or ignorance of) working
going on in other working groups, continually raises problems. As
an example, the earlier SOIS / SM&C MOU failed to acknowledge the existing
of CSS, a set of critical CCSDS interagency cross support service interfaces
between the MOS and the ground comm system that implements the space links.
SM&C is currently asking why SOIS does not adopt the MAL instead
of its own Message Transfer Service (MTS), which has been underway for
years and is already aligned with AMS, a truly interoperable specification.
SM&C apears to now be embarking on a path to define their own
file transfer service (instead of CFDP), radiometric data transfer service
(instead of CSS), and monitor and control services (CSS again), all of
which are define CCSDS interfaces. They state that they are defining
a Service Oriented Architecture (SOA), but have not really defined what
this means and appear to be ignoring work long underway in MOIMS IPR and
SEA IA WGs. <br>
<br>
I would approve this document only after all of these issues are resolved
in a way that is consistent with the body of work already in progress in
the rest of CCSDS.<br>
<br>
Erik Barkley (Approve with Conditions): Although it
is clear that there has been substantial effort in the production of this
document, it tends to read more as a white paper as opposed to a complete
concept document. There are multiple instances of proposals and future
tense hypothetical statements as opposed to direct statement of concept.
This tends to give the reader the impression that this is a direction that
CCSDS is considering pursuing. And I think this tends to expose that we
(CCSDS) do not quite have this properly factored into our overall program
of work.<br>
<br>
The basic concept of establishing an abstract messaging framework along
with generally accepted modern day Service Oriented Architecticture is
interesting and can be argued as the direction to pursue, but I believe
the argument is being made without proper benefit and considerations from
all corners of CCSDS -- for example, the concept makes mention of pursuing
overlaps in various areas but in fact does not elaborate the concept or
approach in this regard. Note that I'm not faulting the working group,
I believe it is incumbent upon all the AD and DADs in CCSDS to more vigorously
coordinate the bodies of work involved, and in particular, I would suggest
that many of the issues require a systems engineering focus within CCSDS.<br>
<br>
To this reviewer, the concept document is a little "unbalanced".
There is much discussion about the overall framework, message abstraction
layer, and common objects in support of the identified mission services.
However, presumably, the main output of all this activity is to standardize
those very mission services identified in the concept book. But there is
very little treatment of the services themselves and how they relate and
how they actually furnish the operational capabilities that they are to
standardize. This treatment should allow conceptual examination of
interactions with the framework thereby offering a conceptual validation
of all that is stated in the document. As the concept document has
a rather impressive scope, I expected to see treatments re usage of the
services for major use cases such as, for example, the use of the services
in near-earth environment, manned missions, deep space/ robotic missions,
etc.<br>
<br>
With regard to the services themselves, there is no conceptual relationship
identified. For example, presumably there are strong relationships
between planning requests, scheduling, and automation. But there is no
information model offered in this regard and no discussion of service timelines
leading from long-term planning to day to day operations. Such analysis
may in fact uncover an accountability service predicated on the M+C service,
but, again, these relationships do not appear to have stated at a conceptual
level in the document.<br>
<br>
As noted above, there are several areas of overlap with other work areas
in CCSDS. The conceptual approach for interacting with the recommendations
emerging or already published in these other areas needs further development.
For example, there is discussion of "network zones"; to this
reviewer this seems premature and largely dependent on the schemes designed
for space internetworking addressing from the SIS area. As another example,
there is discussion of directories, etc. as a common services/basis for
the framework; I believe this would benefit from coordination with the
development of the registry efforts in the SE area. And similarly,
TT+C providers perform planning and scheduling services that have an impact
on mission operations and there is no statement of peer or hierarchical
relationships of these services, for example, with regard to these services
defined by the CSS area.<br>
<br>
Summary: The concept document needs to read more comprehensively
by a) stating conceptual relationships to closely related recommendations
and recognizing where peer-to-peer relationships or hierarchical relationships
etc. exist, b) offering more direct treatment of the services to be standardized
to enable a better conceptual validation that the framework will properly
support those services.<br>
<br>
For the record, I will also state that the document as is, represents a
significant accomplishment in engaging the entire CCSDS community to consider
the big picture.<br>
<br>
Bob Durst (Approve with Conditions): This document
states that it is an overview of a concept for a framework (ref section
1.1). I'm pretty sure I don't know how to use that. <br>
<br>
But if I think about what a *framework* is, I expect that in looking at,
for example, a framework for a building, I should be able to tell what
is and is not part of the building. This document is at a sufficiently
high level of abstraction that it is difficult (for me, at least) to determine
just where SM&C (the building) stops and the application layer protocols
developed by the other areas within CCSDS begin. <br>
<br>
So I’d like to see some clarification about just what it is that SM&C
feels is in scope and what is external to the SM&C work. I believe
that the relationship between this approach to supporting mission operation
interoperability and the (application-layer) protocols and services being
developed elsewhere within CCSDS needs to be clarified. AMS is mentioned,
as is CFDP, but only in "may be" terms. (For file transfers
between space and ground, is something other than CFDP seriously being
considered?) In particular, in section 4, Figure 4-4, is the "CCSDS
AMS Encoding: Blue Book" the AMS specification being developed within
SIS, or a *mapping* to the SIS AMS specification, with that mapping to
be developed by SM&C?<br>
<br>
It seems important that the areas in CCSDS that are developing application
layer protocols should both be clearly seen as *sources* of communication
services to SM&C in this framework and as *recipients* of requirements
from SM&C. Figure 2-3 lumps two CCSDS Areas, one protocol, and
"Other" under "Space Link Services", which makes me
think that this piece of it wasn't really thought out much. Although
AMS and CFDP are mentioned in section 2.3.3 (a good thing), they aren't
mentioned in the references, and the document really doesn't discuss much
about how these protocols, or those of SOIS, might be used to support the
concepts being described here. <br>
<br>
So my condition for approval is to clarify the relationship of the SM&C
work described in this document to the activities (both currently ongoing
and within the identified scope) of the other areas within CCSDS.<br>
<br>
Total Respondents: 6<br>
<br>
No response was received from the following Area(s):<br>
<br>
MOIMS<br>
<br>
SECRETARIAT INTERPRETATION OF RESULTS: Disapproved<br>
PROPOSED SECRETARIAT ACTION: To
be determined<br>
<br>
* * * * * * * * * * * * * * * * * * * * * * * *<br>
CESG E-Poll Identifier: CESG-P-2009-07-002 Reconfirmation of CCSDS
651.0-B-1, Producer-Archive Interface Methodology Abstract Standard (Blue
Book, Issue 1, May 2004)<br>
Results of CESG poll beginning 8 July 2009 and ending 27 July 2009:<br>
<br>
Abstain: 4
(57.14%) (Taylor, Gerner, Moury, Durst)<br>
Approve Unconditionally: 1 (14.29%) (Peccia)<br>
Approve with Conditions: 2 (28.57%) (Shames, Barkley)<br>
Disapprove with Comment: 0 (0%) <br>
<br>
CONDITIONS/COMMENTS:<br>
<br>
Peter Shames (Approve with Conditions): This document
is being offered for re-confirmation, with no identified changes. As
such it could just be re-approved as is. <br>
<br>
However, the document is mis-typed as a Blue Book (grandfathered from the
time when CCSDS did not have a Magenta Book category). In reviewing
the document contents it is clear that it is a procedures document, not
a normative specification for interoperability or cross support. <br>
<br>
Quoting from the "Purpose and Scope" section of the document:<br>
<br>
"The purpose of this Recommendation is to identify, define and provide
structure to the<br>
relationships and interactions between an information Producer and an Archive.
This<br>
Recommendation defines the methodology for the structure of actions that
are required from the initial time of contact between the Producer and
the Archive until the objects of<br>
information are received and validated by the Archive".<br>
<br>
This document should be re-typed as a Magenta Book to correctly fit in
with the rest of the CCSDS documents.<br>
<br>
Erik Barkley (Approve with Conditions): This is a
Magenta Book; if re-labeled as a Magenta book I see no issues with its
release. I can appreciate that there may be some concern about change
in book color, but I believe that CCSDS is attempting to provide more clarity
as to what is an interoperable standard vs., best practice. This
book clearly fits in the best practice category and we should step forward
in declaring it as such.<br>
<br>
Total Respondents: 7<br>
<br>
All Areas responded to this question.<br>
<br>
SECRETARIAT INTERPRETATION OF RESULTS: Approved with Conditions<br>
PROPOSED SECRETARIAT ACTION: Await
resolution of comments<br>
<br>
* * * * * * * * * * * * * * * * * * * * * * * *<br>
CESG E-Poll Identifier: CESG-P-2009-07-003 Final approval of CCSDS
135.0-B-4, Space Link Identifiers (Blue Book, Issue 4, July 2009)<br>
Results of CESG poll beginning 9 July 2009 and ending 27 July 2009:<br>
<br>
Abstain: 0
(0%) <br>
Approve Unconditionally: 5 (71.43%) (Peccia, Barkley, Gerner, Moury,
Durst)<br>
Approve with Conditions: 1 (14.29%) (Shames)<br>
Disapprove with Comment: 1 (14.29%) (Taylor)<br>
<br>
CONDITIONS/COMMENTS:<br>
<br>
Peter Shames (Approve with Conditions): There are
no issues with the document itself. The IPE could equally well have
been documented in "IP Over CCSDS", but that is a Magenta Book
and this is a normative specification that belongs in a Blue Book.<br>
<br>
The condition that must be satisfied is to produce an adequate CCSDS YB
interoperability test report. The offered PPT does not specifically
cover:<br>
<br>
a) that there were two independent interoperable implementations<br>
b) that all of the options specified in the document were tested.<br>
<br>
Chris Taylor (Disapprove with Comment): It is unclear
from the attached rpesentation if there are two independent implementations
and if the test coverage is complete. Please provide more info.<br>
<br>
Total Respondents: 7<br>
<br>
All Areas responded to this question.<br>
<br>
SECRETARIAT INTERPRETATION OF RESULTS: Disapproved<br>
PROPOSED SECRETARIAT ACTION: To
be determined<br>
<br>
* * * * * * * * * * * * * * * * * * * * * * * *</font></tt><tt><font size=2>_______________________________________________<br>
CESG mailing list<br>
CESG@mailman.ccsds.org<br>
http://mailman.ccsds.org/mailman/listinfo/cesg<br>
</font></tt>