SEA CMC/CESG REPORT

1. SEA CMC/CESG REPORT Colorado Springs, CO, USA, 24 January 2007

2. SEA Includes: System Architecture, Information Architecture & Security Working Groups SANA WG (starting to meet as WG now) XML Standards and Guidelines SIG (cross WG effort) Delta-DOR SIG (cross WG effort, not meeting) SGIA BoF (Now has IOAG / agency support, meeting) Registry / Repository SIG (new short term joint effort) Responsibilities Overall architecture for space mission communications, operations, and cross-support Coordinate and collaborate with the other areas about architectural choices and options Support the CESG in evaluating consistency of all area programs of work with the defined architecture Create such working groups and BoFs as are required to progress the work of CCSDS System Engineering AreaOverview

3. System Architecture WG - meeting this week Develop a high level system architecture reference model (and formal methodology and tools - deferred as work item) Finalize Reference Architecture for Space Data Systems (RASDS) V1 Magenta Book, nowout for review Discuss future work on architectural principles & formalisms Information Architecture WG - meeting this week Develop a high level Information Architecture reference model and definitions of active and passive information objects Finalize Reference Architecture for Space Information Management (RASIM) V1 Green Book Define component interfaces and standards w/ MOIMS IPR, formed new Registries / Repositories SIG to develop draft standard interfaces Security WG - meeting this week Develop security overview & threat assessment, and security architecture, framework and related standards Progress Security Architecture and other specific security elements (Key management, Crypto and Authentication Standards) Discussions with other WGs as needed System Engineering Area:Current WGs and BOFs

4. SANA WG - meeting this week Develop detailed requirements for the Space Assigned Numbers Authority (SANA) Develop requirements and SoW New BoFs Space Ground Interoperability Architecture BoF - meeting this week Develop an end to end space / ground cross support architecture and services catalog in response to IOAG request IOAG has now taken lead, has some agency support, JAXA action item to produce draft Plan to develop cross support architecture and service catalog(s) CCSDS will support this effort and leverage RASDS and other current standards efforts Role of this BoF re NASA SCAWG and IOAG Cross Support Architecture is TBD System Engineering Area:Current WGs and BOFs

5. Delta-DOR SIG - not meeting this week Develop detailed requirements for delta differential one-way ranging (Delta-DOR) service Coordinate work in other WGs (SIS/Ranging, CSS/CSTS, MOIMS/Nav) Develop integrated vision of service and interoperability points Develop over-arching documents (MB, GB), as needed XML Standards and Guidelines SIG - meeting this week Develop a set of common standards and guidelines for XML use across CCSDS Coordinate work in other WGs (MOIMS/Nav, MOIMS/SM&C, CSS/SMWG, SEA/IAWG) Product will be a set of guidelines for all CCSDS WG that use XML to follow Considering move to create a new WG System Engineering Area:Current Special Interest Groups (SIGs)

6. SysML Partners have developed a system engineering modeling language based upon UML 2.0. A liaison has been agreed to, which opens up a communication channel between the SEA and SysML groups. The intent is to provide the SysML solution to CCSDS for their validation for application to Space Systems.   SysML agreed to form a liaison w/ CCSDS. SEA, on behalf of CCSDS, has agreed to that liaison and several joint meetings have been held. The SysML spec is currently at version 1.0 in Finalization Task Force (equivalent to RB version 2 validation). At least four UML tool vendors have developed SysML 1.0 compliant versions of their tools. A summary presentation is available from the SysML web site. An informal liaison has been developed with ISO/IEC JTC 1 / SC7 / WG 19 which is developing an UML for RM-ODP approach. This opens up a useful communication channel between the two groups. Our interest is to validate the RASDS to the RM-ODP and to provide feedback to the SC7 WG 19 on its applicability to Space Systems.   The JTC 1 / SC 7 / WG 19 chair is interested in an informal liaison w/ CCSDS. It appears, however, that the most effective approach may be for our interested members to join them in developing the UML for ODP spec and future revisions to RM-ODP which will follow. Liaisons

7. System Architecture WG RASDS review RB (Agency Review) IOAG Cross Support Architecture WB Discussion CCSDS Architecture Principles WP Discussion & plan Security WG Security Architecture WB Discussion, RB plan Encryption & Authentication WBs Discussion (magenta?) Key Management WP Discussion Information Architecture WG RASIM GB ready for CESG RASIM Use Cases & patterns WB Discussion SANA WG Requirements & content WP Discussion SoW approach WP Discussion XSG SIG Guidelines document WB Discussion BoF / WG Plans Future Work Discussion Delta-DOR SIG Overview document WP Discussion (no meeting) Registry / Repository SIG IA / IPR Registries Draft WP Discussion & plan SEA Summary Document Status

8. Systems Architecture WG Goal: Develop a reference architecture and a formal representation method Working Group Status: Active ___ Idle ___ Will be terminated _X_ Working Group Summary Situation: Working Group Summary progress: RASDS document released as a Red Book for Agency review SAWG needs to exist until we process RIDs and publish the final MB. Problems and Issues: Ordered by CMC to terminate Development of a formal model is important for making architectural information available for software tools - halted SAWG Summary Technical Status

9. A CESG poll for “Approval of RASDS for Agency Red-1 review” was posted in March 2006, and comments were received. The WG revised the RASDS document based on the received comments and released it as a Red Book for Agency review in January 2007. RIDs are due 9 April 2007, expect them to be processed and document updated prior to Fall 2007 meeting. SAWG Executive Summary

10. Define a reference architecture that provides a framework for generation of space data systems standards and development of space data systems. Document the reference architecture identifying basic elements. Develop a document (GB) that provides to the other Working Groups and BoFs guidelines on how to apply the reference architecture. Develop formal methods for representing space data systems architectures that will enable sharing of architectural information among engineers. Develop tools that will facilitate design, modeling, and simulation of system architectural designs. SAWG Summary of Goals and Deliverables

11. Edits and changes to the RASDS RB were reviewed and discussed. RIDs are due 9 April 2007. Plan for resolving RIDs was discussed. Nominal plan is to complete and publish MB by the Fall 2007 Meeting, assuming there are not major issues identified. With regard to items 4 and 5, the WG reviewed the activities of the ISO/IEC JTC1/SC7/WG19 that is defining a UML profile for RM-ODP. SAWG Progress Achieved

12. No Agency resources are available to perform work items 3, 4, and 5 defined in the Charter. How best to support the development of Cross Support Service Architecture by IOAG? RASDS Green Book has been deferred, resources are supporting IOAG Cross Support Architecture effort. RASDS is to be used to describe complex space data systems but people involved in complex space data systems rarely come to CCSDS. Some missions have successfully used RASDS as part of their mission design process. Whether to establish a liaison relationship between CCSDS and ISO/IEC JTC1/SC7 or between ISO TC20/SC13 and ISO/IEC JTC1/SC7? Update RASDS when RM-ODP is updated? RM-ODP will be updated by the ISO/IEC WG that developed the original RM-ODP spec and the revised standard will be published in two years. We may need to revise RASDS based on the revised RM-ODP. SAWG Open Issues

13. SecWG SUMMARY TECHNICAL STATUS • Security WG • Goal: • Working Status: Active _X_ Idle ____ • Summary progress: Five documents actively being produced (Security Architecture, Encryption, Authentication, Key Management, Secure Interconnection). All docs green. • Progress since last meeting: Completed Threat, completed secure interconnection doc, consensus on Encryption and Authentication Algorithm documents, positive movement on Security Architecture doc. • Problems and Issues: Resources – need to ensure continued participation from all member agencies

14. Attendees from BNSC, ESA/ESOC, ESA/ESRIN, DLR, NASA/GSFC, NASA/MSFC, NASA/JSC and NASA/JPL. CNES and ASI were originally going to attend but were not able due to illness and programmatic issues. Major participation by NASA from multiple centers including JSC. Discussed and revised the SecWG Security Architecture. General consensus that this is a high priority document that should be issued as a Magenta book (a la RASDS). Supports Packet or IP networking and allows security services at physical/link layer, network layer, and at application. Needs mission class use cases (a la the threat document) to be added with inputs from the SecWG members. Discussed the encryption and authentication draft documents. Agreed to publish as Magenta books after revising per ESTEC comments (on encryption book) and changes to hash algorithm as discussed (on authentication book). Joint meeting held with SANA to discuss security implications of SANA registries and security registries (e.g., identity management). Discussed key management document and proposal written by ESA SecWG Executive Summary

15. Secure Interconnection Guideline has been revised and submitted to the secretariat for editing and publication. Security Architecture document will be revised based on meeting discussions. Encryption and Authentication Algorithm documents will be revised per ESTEC comments, telecon discussions between NASA-ESA-BNSC, and meeting discussions. To be published as Magenta books. Early discussions regarding potential security-related registries with SANA. Excellent discussion and document on key management. Generated a list of new work items/documents to be considered for future. Continue to work with other Areas and their WGs with respect to security. SecWG Summary of Goals and Deliverables

16. General agreement that the Security Architecture (as revised) is on the right path. With minor revisions and the addition of “use cases” for each of the mission classes (a la the threat document), the Security Architecture document should be good to go. Reviewed the encryption and authentication algorithm documents. Consensus that these documents should be issued as Magenta books. Encryption algorithm might be one of a suite of algorithms and/or modes Agreement that the authentication document should not require SHA-1 in light of further work in breaking the algorithm and announcements: Microsoft is moving away from SHA-1 and NIST has issued guidance for the US Govt to move away from it by 2010. Document will now require SHA-256 and allow the use of other algorithms. Joint meeting with SANA to discuss implications of security on registries and the creation of security registries (e.g., identity). At a minimum, there will need to be user identification, authentication, and access controls applied to the SANA registries. There probably need to be some security registries (e.g., algorithm IDs, protocol IDs) but its less clear if there should be identity registries (e.g., PKI-like functionality, access control lists). An excellent key management document was written and presented by ESA providing a good start on the path towards specifying a CCSDS key management document (Magenta, Blue, color not determined yet). SecWG Progress Achieved

17. IAWG SUMMARY TECHNICAL STATUS • IAWG WG • Goal: • Working Status: Active _X_ Idle ____ • Summary progress: RASIM GB document is ready for submission to CESG review. • Progress since last meeting: Established that RASIM is ready for outside review. Co-chaired Registry / Repository SIG meeting that established near term plan for reference model. • Problems and Issues: Limited resources from member agencies. Need support from Gurus in other relevant WGs for Reg / Rep SIG use cases.

18. Two half day meetings were held with other WGs to discuss a plan for developing a registry model. It was decided that a 4 month effort will be conducted to define a high level architecture. A series of telecons and a face-to-face meeting will be held during this time. This was a major break-through from past meetings. Multiple CCSDS WGs and Agencies are onboard. The draft Information Architecture Green Book RASIM was discussed. No additional comments have been provided since being sent out for review in 2006. The GB will be forwarded to the CESG for review and approval. The meeting also discussed the importance of developing some best practice case examples using RASIM modeling and functional components for science and mission operations. Application to DSMS Information System Architecture (DISA) Application to Constellation IAWG Executive Summary

19. There was significant progress in forming a CCSDS effort for registry definition. A Registry / Repository SIG has been formed to move this work forward Membership is drawn from IAWG and IPR WGs, members from other WGs (SM&C, SMWG, SANA, NavWG) are being solicited Use cases and scenarios are to be drawn from CCSDS WGs and agency needs for these services Near term plan for reference model and interface definitions Schema registry and service registry are high priorities for IPR and IA WGs Expect other kinds of compliant registries to be developed in other WGs like SANA, SM&C, SMWG There was minimal additional feedback on the IA green book (RASIM) which defines much of the base concepts that are needed for the more detailed information architectures like registries and repositories. Reg / Rep SIG is expected to use RASIM as guiding document for developing interfaces and service definitions IAWG Progress Achieved

20. While there is participation in IAWG, it is still minimal across the agencies. Many agencies now appear to be discussing information architecture concepts identical to IAWG proposal and developing systems that implement these kinds of architectures (NASA, ESA, CNES, BNSC) Having a core architecture document that provides standard definitions of terminology and interface concepts is becoming critical Registries and repositories work is critical across several CCSDS WGs (SM&C, SMWG, SANA, NavWG) Need participation from members of these WGs Expect WGs to do prototyping, refinement and validation of reference model developed by Reg / Rep SIG Cross WG coordination is still difficult WGs run different lengths which makes scheduling tough Several WGs were scheduled concurrently, making participation and cross WG efforts very difficult Need to consider merging XSG work into IA at some point IAWG Open Issues

21. SANA WG Goal: Establish a mechanism by which CCSDS can develop and operate a top level registry service. Working Group Status: Active _X_ Idle ___ Will be terminated __ Working Group Summary Situation: Working Group Summary progress: Used working group time to revise SANA requirements and SOW. Will be sending this list of revised requirements and SOW out to working group members for comment Problems and Issues: Need to revise SANA charter to reflect schedule for SANA deliverables Status: OK CAUTION PROBLEM Comment: Need agency support SANA Summary Technical Status

22. SANA WG OVERVIEW • Charter and objectives of SANA Working Group: • Focus on Engineering data, not science data • Provide the mechanisms, processes and documentation required for a CCSDS registry capability • Provide detailed requirements for a CCSDS registry • Integrate current CCSDS registry processes into a unified standardized framework • Utilize work on registries being done in other CCSDS working groups (IAWG & IPR) • Propose a SANA advisory group and develop rules and processes including resources required, look at IANA for best practices • Provide an assessment of categories 1 through 4 information sources for registry requirements in a SANA Green Book • Present findings in an informal requirements review prior to further activities • Document existing identifier spaces that CCSDS requires and to identify any special constraints imposed by those identifier spaces and that a particular registry exists and procedures for interaction with it • Define processes and standards to the numbering and identifier requirements • Define and document a statement of work for the ongoing operation of the SANA function • Present SOW to the CMC • Develop implementation and operation plans and cost • Goals for the January 2007 CCSDS meeting: • Review and obtain consensus on the SANA requirements and SANA SOW

23. Summary from joint meeting with Security Working Group Overall consensus was that SANA would use the products coming out of the security group. This will include the security guidelines and recommendations and any other products that have relevance to a SANA registry to provide access control within the registries and protect information in the registries. Suggested use of common login for CCSDS services, SANA and CWE / web site Summary from main SANA WG meeting Agreed that we needed to continue further refinement of requirements and submit for comment to whole group and CESG Expect to use products and recommendations coming out of the Registry/Repository SIG group Agreed to develop a draft implementation plan Evaluating “fast-track” prototype approach vs more formal SoW approach SANA Executive Summary

24. Catalyzed by IPR Study on XML Schema Namespaces, Specialization and Schema Repository Services Best Practices that were presented to the CCSDS/OMG Plenary in Atlanta. The SIG includes members from the NavWG, SMWG, SM&C WG, IPR WG and IAWG who are the editors of the draft CCSDS recommendations that used XML Schema as a normative portion of the specification and an ESA and CNES representative. Short-term deliverables CCSDS XML Schema Namespace and Versioning - NASA editor Define an IETF RFC to obtain a CCSDS URN domain - ESA Editor Long-term needs Dissolve the XSG after Oct 2007 meeting and create a BOF to: Develop a CCSDS NDR and Best Practices Document Look at UBL architecture as a basis for space operations information architecture Define various levels of XML Schema reusable components based on the UBL model Investigate commercial tools as a basis for CCSDS XML Schema Service (Registry and Repository) WG could be formulated under restructured IAWG charter or otherwise. Regardless of approach, “XML guru” resources from other WGs will be required. XSG SIG OVERVIEW CCSDS XML Standards and Guidelines SIG

25. Meeting Summary Due to WG schedule collisions & conflicts the XSG met briefly Saturday morning and final drafts were distributed, but examples will be done via telecon. Lou Reich presented briefing on a new XML Schema extension technique which will be used in third party extensions Status Internal drafts of both IETF RFC to obtain a CCSDS URN domain and the CCSDS XML Schema Namespace and Versioning documents were completed in early January Developing final drafts for review by the CESG has been delayed due to major releases of OASIS, UBL and UN/EDIFACT Naming and Design Rule version 2 documents and lack of resource/priority The editors feel that current drafts are final except for examples and should be compliant with the UBL 2.0 Naming and Design Rules Final drafts of the should be sent to the CESG by March 31,2007 XSG SIG Progress and Current Status

26. Over the next nine months, the XML SIG will be responsive to the need of the Registry/Repository SIG Architecture efforts and the MOIMS/IPR XML Schemas Registry/Repository effort through supplying use cases and technical input as requested. Significant resources will be needed both to complete the XML Schema NDR and to supply the domain knowledge to enable reusable and interoperable XML Schemas The XSG recommends the XML SIG be dissolved after the Fall 2007 meeting and a BOF be created so appropriate levels of resource can be assigned to this effort. Support from the “XML Gurus” in other working groups is going to be a continuing issue for this activity, regardless of how it is chartered. The downside of not doing this correctly is that we will, as a standards organization, fail to present XML standards that are self consistent, well integrated and interoperate properly. XSG SIG Issues

27. D-DOR SIG SUMMARY TECHNICAL STATUS • Delta-DOR SIG • Goal: Standardize cross-support for Delta-DOR measurements • Working Status: Active _X_ Idle ____ • Summary progress: Did not meet in Colorado; One document actively being produced (Delta-DOR Operations White Book). • Progress since last meeting: Revised White Book; Developed roadmap to demonstrate inter-agency operability; Exchange of tracking data. • Problems and Issues:: Should White Book evolve into Green or Magenta Book ?

28. The Delta-DOR SIG did not meet in Colorado Springs Work has been done and continues through e-mail exchange. Delta-DOR Operations White Book reviewed after Rome Meeting and updated in November 2006 (SIG limited version) to add background information to address the issues highlighted at the June 2006 meeting. Additional SIG review finalized by February 2007. White Book distribution for CCSDS wide review in February (main addressees: SLS/RNG, CSS/CSTS and MOIMS/NAV). Validation of inter-operability between the NASA Delta-DOR system and the ESA Delta-DOR system has begun. Finalization and discussions between SIG and relevant Working Groups in the Fall 2007 meeting. Need decision for either Green or Magenta Book. D-DOR SIG Executive Summary

29. Registries / Repository SIG Joint membership from IAWG & IPR WG Near term plan to develop reference model for service interfaces Plan that prototyping in several WGs will validate and refine reference model and interface specifications Space Data Systems Standards Reference Model BoF Develop a Space Data Systems Standards Reference Model utilizing RASDS and IOAG CSSA Review the Cross Support Service Architecture (CSSA) developed by IOAG, the CSS reference model and SM&C reference model Ensure consistency between the above models, define a glossary of terminology Use the model to describe the major interfaces and interactions of the CCSDS family of space data system standards Requires expertise from several key WGs SEA - Proposed New WG / BoF

30. SEA has previously identified need for CCSDS Architecture Principles, as called out in A02.1-Y-2 & A00.0-Y-9. SEA will develop draft document, either as MB (or YB?), for CESG and CMC approval. SEA will need to support the development of Cross Support Service Architecture initiated by IOAG. No defined relationship to do this now exists. Could be SGIA or SAWG, but will need support from other WG experts. Consider focus workshop of 2-3 days duration, with both IOAG and CCSDS reps, to help create the document. Agreement within SEA about need for ops concepts as starting point for architecture development. MOIMS SM&C WG has defined terms Interaction Pattern (IP) and Message Exchange Pattern (MEP) which are similar in design and terminology to CSS SMWG, but are in no way aligned. This appears to be both redundant and confusing. Recommend harmonizing these approaches. SEA Cross Area WG / BOF Issues

31. XML Standards & Guidelines adoption process, MB? BB? YB? Delta-DOR end to end process, document development NASA / Constellation & SCAWG activities Interoperability and cross support Manned & robotic exploration at the Moon and Mars Need for unified inputs from CCSDS and member agencies for technical feedback, architecture, and interoperability Need for CCSDS security registry, identity management? Support at least CCSDS developed & operated services, web pages & SANA Color of security encryption / authentication docs? These should be Blue, but there is some ESA member resistance. May make them Magenta as a result. Color of IAWG Reference Architecture for Space Information Management (RASIM) Has been proposed as Green Book because of individual member objections, Based on contents and purpose should be a non-binding Magenta Book. SEA - Other Issues & Concerns

32. BACKUP SLIDES

33. CCSDS A02.1-Y-2.Restructured Organization and Processes for the Consultative Committee for Space Data Systems. Yellow Book. Issue 2. April 2004: 1.4.6 Space Assigned Numbers Authority (SANA) The core registrar for the CMC’s activities is the SANA. Many space mission protocols require that someone keep track of key protocol numbering assignments that were added after the protocol came out. Typical examples of the kinds of registries needed are for Spacecraft IDs, protocol version numbers, reserved APIDs and SFDU Control Authorities. The SANA provides this key configuration management service for CCSDS. The CMC approves the organization that will act as the SANA. Its public interface is focused through web-based services provided by the Secretariat. Space Assigned Number Authority (SANA) Motivation

34. Scope of SANA (in green) Overlap: Processes And pointers • Pointer to all registries • Process definition for all registries • (Points to IAWG and IPR books for lower level registry requirements) Others… SpaceCraft ID ESA PUS IDs Others… SCPS Others… IPv6 In space New external sub-registries Legacy sub-registries New CCSDS-run sub-registries