[Moims-ipr] Fw: [CESG] Results of CESG polls closing 27 July 2009

Wed Jul 29 02:55:12 EDT 2009

----- Forwarded by Nestor Peccia/esoc/ESA on 29/07/2009 08:54 -----

CCSDS Secretariat <tomg at aiaa.org> 
Sent by: cesg-bounces at mailman.ccsds.org
28/07/2009 23:31

To
cesg at mailman.ccsds.org
cc

Subject
[CESG] Results of CESG polls closing 27 July 2009

CESG E-Poll Identifier:  CESG-P-2009-07-001 Approval of update to CCSDS 
520.0-G-2, Mission Operations Services Concept
Results of CESG poll beginning 6 July 2009 and ending 27 July 2009:

                 Abstain:  2 (33.33%) (Taylor, Gerner)
 Approve Unconditionally:  1 (16.67%) (Moury)
 Approve with Conditions:  2 (33.33%) (Barkley, Durst)
 Disapprove with Comment:  1 (16.67%) (Shames)

CONDITIONS/COMMENTS:

     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:

Major issues:
- Unresolved overlaps with other WGs (CSS (SM, CSTS), MOIMS (Nav, IPR), 
SEA (IA, Reg/Rep), SIS (CFDP, AMS), SOIS (message transfer service))
- Assertions about what is needed to make a real "Blue Book", i.e. both 
the MAL and a technology mapping, taken together.
- Confusing descriptions of different MOS services (planning, scheduling, 
automation)
- Lack of clarity of relationship between use of MAL and ?technology 
bindings? for interoperability versus "service specific encodings"
- Use of "SOA" terminology without adequate explanation or relationship to 
precedent related CCSDS work

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. 

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.

     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.

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.

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.

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.

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.

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.

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.

     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. 

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. 

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?

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. 

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.

Total Respondents:  6

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

     MOIMS

SECRETARIAT INTERPRETATION OF RESULTS:  Disapproved
PROPOSED SECRETARIAT ACTION:            To be determined

* * * * * * * * * * * * * * * * * * * * * * * *
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)
Results of CESG poll beginning 8 July 2009 and ending 27 July 2009:

                 Abstain:  4 (57.14%) (Taylor, Gerner, Moury, Durst)
 Approve Unconditionally:  1 (14.29%) (Peccia)
 Approve with Conditions:  2 (28.57%) (Shames, Barkley)
 Disapprove with Comment:  0 (0%) 

CONDITIONS/COMMENTS:

     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. 

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. 

Quoting from the "Purpose and Scope" section of the document:

"The purpose of this Recommendation is to identify, define and provide 
structure to the
relationships and interactions between an information Producer and an 
Archive.  This
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
information are received and validated by the Archive".

This document should be re-typed as a Magenta Book to correctly fit in 
with the rest of the CCSDS documents.

     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.

Total Respondents:  7

All Areas responded to this question.

SECRETARIAT INTERPRETATION OF RESULTS:  Approved with Conditions
PROPOSED SECRETARIAT ACTION:            Await resolution of comments

* * * * * * * * * * * * * * * * * * * * * * * *
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)
Results of CESG poll beginning 9 July 2009 and ending 27 July 2009:

                 Abstain:  0 (0%) 
 Approve Unconditionally:  5 (71.43%) (Peccia, Barkley, Gerner, Moury, 
Durst)
 Approve with Conditions:  1 (14.29%) (Shames)
 Disapprove with Comment:  1 (14.29%) (Taylor)

CONDITIONS/COMMENTS:

     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.

The condition that must be satisfied is to produce an adequate CCSDS YB 
interoperability test report.  The offered PPT does not specifically 
cover:

a) that there were two independent interoperable implementations
b) that all of the options specified in the document were tested.

     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.

Total Respondents:  7

All Areas responded to this question.

SECRETARIAT INTERPRETATION OF RESULTS:  Disapproved
PROPOSED SECRETARIAT ACTION:            To be determined

* * * * * * * * * * * * * * * * * * * * * * * *
_______________________________________________
CESG mailing list
CESG at mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/cesg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/moims-ipr/attachments/20090729/b9d3fc13/attachment.html