520-WP-001-001 ECS Response to NASA DID 304 CSMS Comments White paper - Not intended for formal review or Government approval. White Paper September 1995 Prepared Under Contract NAS5-60000 RESPONSIBLE ENGINEER Mac McDonald /s/ 10/2/95 Mac McDonald, Release A System Engineer Date EOSDIS Core System Project SUBMITTED BY Parag N. Ambardekar /s/ 10/2/95 Parag Ambardekar, Release A Manager Date EOSDIS Core System Project Hughes Information Technology Corporation Upper Marlboro, Maryland This page intentionally left blank. Abstract This white paper is a response to comments received from NASA regarding the CSMS DID 304 published for PDR. Keywords: Level-4, Requirement, Segment Requirements Specification, CSMS This page intentionally left blank. Contents Abstract 1. Introduction 1.1 Purpose 1 1.2 Organization 1 1.3 Review and Approval 1 2. ECS Response This page intentionally left blank. 1. Introduction 1.1 Purpose The purpose of this white paper is to respond to comments made by NASA in a letter dated May 1, 1995. The letter was from Rebecca L. Ragusa to R. L. Raisola. The subject line of that letter was "NAS5-60000; CSMS Requirements Specification (F) March 1995." These comments were made against the PDR version of CSMS's DID 304. 1.2 Organization This paper is primarily a table presented in section 2 with NASA's comments in the left column and ECS's responses to these comments in the right column. 1.3 Review and Approval This White Paper is an informal document approved at the Office Manager level. It does not require formal Government review or approval; however, it is submitted with the intent that review and comments will be forthcoming. Most responses presented here are or will be reflected in the RTM database. Some comments and their responses cannot be reflected in the RTM database. Comments such as the grouping of requirements would not be apparent until the requirements are published again. This publication is planned for the Release B IDR time frame as the Release B SDPS/CSMS Segment Requirements Specification, DID 304-CD-005-001. Questions regarding technical information contained within this Paper should be addressed to the following ECS contact: Mac McDonald Release A System Engineer (301) 925-0364 mac@eos.hitc.com Questions concerning distribution or control of this document should be addressed to: Data Management Office The ECS Project Office Hughes Information Technology Corporation 1616 McCormick Drive Upper Marlboro, MD 20775 2. ECS Response 2.1 Response Table 2.1-1 presents the ECS response to comments in a NASA letter dated May 1, 1995 regarding the NASA review of the PDR version of CSMS DID 304. The "NASA Comment" column was scanned in from hard copy and, therefore, may contain errors as a result of this process which may not have been detected and corrected manually. Table 2.1-1. ECS Responses to NASA Comments (1 of 22) NASA Comment ECS Response Comment 1: Level 4 requirements, in general, do not cover the functionality of each of the Level 3 requirements in sufficient level of details. In some cases, Level 4 requirements cover only the partial functionality of level 3 requirements. The CSMS level 4 requirements were written to provide a detailed description of requirements that meet the functionality defined in the level 3 requirements (or parts thereof) that apply for Ir-1 and Release A. In many cases, level 3 requirements that list multiple functionalities are only partially fulfilled in these releases. In addition, the non-specific nature of some level 3 requirements occasionally makes it difficult to completely cover the full functionality of a level 3 requirement. While it is somewhat difficult to provide a response to comments this general in nature, we would be glad to respond to any specific examples that are identified. Comment 2: Level 4 functional requirements are incomplete. For example; Level 4 requirements do not exist for the following Level 3 ESN functional requirements. The level 4 tracings are in fact complete for all Ir1 and Release A level 3 requirements. The CSMS DID 304 provides requirements for Ir1 and Release A only. The three listed level 3 requirements are not mapped because ESN- 0700 and ESN-1637 are Release C and Release B requirements (respectively). ESN- 1330 is not mapped since the level 3 is (to quote the requirement directly) "...as required by IRDs." Thus far, no IRDs have included this requirement (and none are expected to do so in the Ir1 or Release A time frame), so no level 4 has been generated. Comment 3: The traceability of the following level 3 requirements is missing in Level 3 to Level 4 requirements traceability matrix in Appendix D An analysis of the requirements traces has been completed and updates made in RTM as required. All of the listed level 3 requirements now have traces (except for ESN-1635, which is a release B requirement) and will be incorporated in Appendix D of the next update to DID 304. Table 2.1-1. ECS Responses to NASA Comments (2 of 22) NASA Comment ECS Response Comment 4: No detailed explanation has been given for the preliminary SDPS Network data flow sizing estimates provided in Appendix A (Tables A-5 and A- 6). The tables contain few TBDs. In order to verify the data flow sizing estimates, it is very important to know as to how these numbers were derived from the technical baseline. The preliminary SDPS Network Data Flow Sizing for Release A was based on a static analysis of the data flows between the SDPS components and information available at the PDR time frame. The estimated "raw" data flows (listed in Table A-5 and A-6) were derived using Adhoc Working Group for Production (AHWGP) information. The derivation of the flow sizes for each Release-A DAAC is available and can be provided. Please note that these preliminary flow estimates have now been completely revised (for the CDR) based on the dynamic modeling analysis, the updated AHWGP input (January 1995 technical baseline) and a better understanding of the flow interactions between the various subsystems at a DAAC. Details of the revised calculations are available. Comment 5: Level 3 to Level 4 requirements traceability needs to be checked very thoroughly to make sure that level 3 functional requirements are covered by the Level 4 requirements in sufficient details. An analysis of the requirements traces has been completed and updates made in RTM as required. All release A level 3 requirements are covered. Attachment 1.1 Missing Trouble Ticket Capability Reference: Section 5.2.2.1.2 Description: Response to ECS PDR RID # 180 indicates there should be requirements for trouble ticketing facilities in Release A, however requirements relating to trouble tickets could not be found. Fault identification requires collection & tracking externally reported faults, however none of the Fault Management requirements support automatic or manual generation of trouble tickets, managing or updating trouble tickets. Recommendation: Include requirements that will enable operators to manually (or automatically) generate and track trouble tickets Level 4 requirements for trouble ticketing have been approved by the ECS CCB. These requirements are currently being incorporated in RTM. Table 2.1-1. ECS Responses to NASA Comments (3 of 22) NASA Comment ECS Response 1.2 Missing Use of SDPS Archive Reference: Section 4.1.2.1.2, 4.1.2.2.2, 5.1.1.2, Table 5.1-2 Description: Requirement C-HRD- 11335 - 11345, - 12335, - 12345 identify an interface to the ECS Data Server which is not part of the MSS MHCI nor identified as a subsystem interface in Table 5.1-2. Recommendation; Include MSS input & output requirements to the SDPS segment for archive/retrieval of MSS data. If appropriate, state the specific hardware requirements that are imposed on the MSS servers (e.g., special port or direct communication connections between MSS servers and ECS Data Server). The use of the SDPS archive by the MSS will not require any additional hardware requirements on the MSS servers. Therefore, no additional hardware requirements are needed. 1.3 Missing MSS Printer Graphic Resolution Reference: Section 4.1.2.4 Description: Requirement C-HRD- 13900 does not sufficiently define printer requirements for MSS operations requiring graphics of multiple resource utilization trends. Recommendation: Include a MSS Printer requirement that specifies the print density (e.g., 300 dpi) or the capability to print with the same resolution as the workstation display. A new requirement stating that 300 dpi will be the minimum print density for MSS printers is currently being added via the CCR process. 1.4 Missing Common Management Service Requirements Reference: Section 5.2.1.3.2 Description: There are missing requirements for 1) importing site-specific physical network topologies, 2) importing site-specific facility maps, and 3)providing the capability for management applications to update the managed object database. Recommendation: Add requirements that will provide the capability to define (e.g., MUI input, file import, or auto-discover) site- specific physical network topologies. Add requirements to provide the capability to import site facility maps. Add requirement for capability to update (via API) the managed object database. These requirements are included in the physical configuration management level 4 requirements that have been approved by the ECS CCB. These requirements are currently being incorporated in RTM. 1.5 Missing Statistics Generation Requirements Reference: Section 5.2.1.6.2 Description: fault identification requires an analysis capability using statistics similar to those provided in C-MSS-90080, however identification also involves statistical analysis such as time series analysis, linear least-squares fits, harmonic analysis, as well as others. Recommendation: Add requirements to retrieve time series, support performing a wide variety of statistical analysis using statistical analysis packages. Fault identification, diagnosis and isolation, in Release A will be supported by tools, including an event browser and diagnostic tests. Office Automation tools (spreadsheet) provide the statistical functions required for trends analysis in Release A Table 2.1-1. ECS Responses to NASA Comments (4 of 22) NASA Comment ECS Response 1.6 Missing DBMS Performance Reporting Requirements Reference: Section 5.2.1 6.2 Description: DBMS requirements do not include a capability to provide access to DBMS performance metrics via the ECS management protocol SNMP. Recommendation: Add a requirement for the DBMS to support management access to performance information via SNMP. For a number of managed objects, performance monitoring can be done in several ways, with the use of SNMP being one method. As for the RDMS, there is no SNMP standard; the vendors have yet to agree. The DBMS is listed, however, in the general performance monitoring requirement (C-MSS-66000) to reflect the fact that whatever vendor-provided DBMS performance monitoring capability is available will be used. 1.7 Missing Dedicated Terminal Standards Reference: Section 4 1 2.1 I Description: Requirement C-HRD -11120 and -12120 indicate the dedicated terminal must be compatible with the Management Workstation display device, however the requirement does not sufficiently identify the required compatibility. This terminal will be used by the M&O staff, and the keyboard and display should have the same user interface as other ECS workstations. This terminal should satisfy minimum standards for user interface devices. Recommendation: Add requirements for MSS server dedicated terminals similar to C-HRD-13105 (keyboard) and C-HRD- 13110 (monitor). The dedicated terminals will be selected through a COTS procurement. The common user interface will be one of the aspects on which vendors will be graded, but may not necessarily be the deciding factor. For this reason, it has not been included as a level 4 requirement. 1.8 Missing Alarm-Event Correlation Reference: Section 5 2.2.2.2 Description: Fault Management Application service is missing requirements for the capability to define & detect correlative management events that are the result of a fault in another managed object. Without this capability, operators may be flooded with multiple fault alarms that resulted from a single fault of another managed object (see C-MSS- 60200). Recommendation: Add requirements for the capability to define and display managed object states and state transition rules (e.g., correlative event filtering rules) for a hierarchy of managed objects. The functional capability of automatic correlation of fault (alarm)-event correlation is a Release B capability. Therefore, it is not addressed in this document. 1.9 Missing Statistical Analysis Tools Reference: Section 5.2.3 2.2 Description: Performance Trending requirements do not include a capability to provide statistical analyses of metric values. Recommendation: Modify or add requirements to include computation and display of results from statistical analysis packages such as MatLab (MathWorks) or S-PLUS (StatSci). The analysis capabilities provided by the performance management applications and the spreadsheet applications are sufficient for Release A. Additional statistical analysis tools may be provided in the Release B time frame. Table 2.1-1. ECS Responses to NASA Comments (5 of 22) NASA Comment ECS Response 1.10 Missing Baseline Manager Interface Requirements Reference: Section 5 3 1 2 1 Description: All interfaces to the configuration management application appear to be represented by requirement C-MSS-40290; providing generic interfaces. This requirement lack preciseness required to enable detailed design For example, C-MSS-40060 identifies a requirement to provide configuration item level of assembly and version history, however a specific requirement to interface with another application cannot be found. Recommendation: Identify specific configuration management requirements for interfaces to other applications and subsystems. Indicate whether all updates to baseline information are expect. to be entered locally via the interactive user interface, or whether data, such as level of assembly & version history, will be provided in a specific format from other applications (e.g., see Context Diagram Figure 5.3-1). Operationally, configuration management application service components need not interact with other peer-level applications and subsystems in release A, thus no detailed interface requirements are needed. Most data update occurs via interactive user interfaces, and exchanges of baseline management data occur within the confines of the service (among its COTS CM tools). The requirement to accept baseline management data via formatted data files (C-MSS-40290) is intended primarily to ensure a degree of integration is achievable among the COTS CM tools. The format of these data files is COTS dependent. 1.11 Missing Requirements for Management User Interface Reference: Section 5.3.1.2 Description: The configuration management service appears to depend heavily on user interaction, however the service does not include requirements for user interface standards (e.g., MOTIF and any additional ECS Project-level conventions). Recommendation: Add requirements for ECS user interface standards and conventions. A working group is currently developing ECS user interface standards on a project-wide basis. In addition, any ECS user interface requirements should be addressed in one section of the requirements document, otherwise the same level 4 requirements will be repeated many times throughout the document. Requirements for user interface standards are currently listed in the MUI section (e.g., C-MSS-12010). 1.12 Missing Requirements for Performance Metrics Reference: Section 5.3.1.2 Description: The configuration management service does not include requirements for providing performance metrics (e.g., DBMS performance statistics) in accordance with CSMS management protocol standard SNMP. Recommendation: Add requirements for reporting configuration management service performance metrics through the use of SNMP. Configuration management application service components do not need to report performance metrics through the use of SNMP. The Management Agent Service provides proxy agents for ECS applications that cannot be managed via SNMP (C-MSS-36100). These proxy agents, together with CMAS event logs (C-MSS-40990), report performance metrics. Table 2.1-1. ECS Responses to NASA Comments (6 of 22) NASA Comment ECS Response 1.13 Missing Requirements for Archive of CM data Reference: Section 5.3.1.2 Description: The Configuration Management Baseline Manager and Software Change Manager References are missing requirements to archive and retrieve CM data (documents, source code, user notes, CCRs, etc.). Recommendation: Add requirements for archive and retrieval of CM data to ensure the ability to re-create products though out the program. Neither the Baseline Manager nor the Software Change Manager need to "archive" CM data in order to recreate products. Data sufficient to re- generate the current and first previous version of each ECS control item can be retained on- line. The need to retain CM data in an archive (off-line) for longer time periods has not been formalized. 1.14 Missing Requirements for Management Information Reference: Section 5.4.1.2 Description: The MSS Management Agent Service requirements indicate there will be several types of management agents. however there are no requirements defined for management attributes that would be common across ECS applications and/or common for specific types of ECS applications (e.g., DBMS, file servers). Recommendation: Add requirements for common management attributes. Management attributes are a function of the management applications that they are supporting. Therefore, any requirements for ECS applications should be listed in the various management application sections. Requirements for these attributes are being added to the performance management and fault management sections via the CCR process. New ECS application-specific fault and performance metrics will, however, continue to be identified as the design is implemented, so the metrics identified in DID 304 should not be considered to be all- inclusive. Common management attributes for databases and file servers are not included since they are not required. Databases may, however, be monitored to the extent that vendor-provided capabilities allow. Table 2.1-1. ECS Responses to NASA Comments (7 of 22) NASA Comment ECS Response 1.15 Refine intrusion detection and reporting requirements Reference: Section 5.2.4.5 Description: The following comment and recommendation is based on the contents of RID 197 submitted by Arthur Gaylord. The specifications only detail the requirements for periodic checking for security audit trails. HAIS should consider more active measures such as reliable, real-time reporting of security alerts as well as some degree of intrusion avoidance counter measures, such as the deactivation of accounts under attack, etc. Measures should be taken to detect denial of service attacks and to react to them, especially for key services such as security, naming, and events. Router based filtering is not a sufficient countermeasure. Recommendation: Include mechanisms/requirements for identifying and reacting to attacks and providing both timely and reliable notification for reporting security alerts. . A requirement for reliable notifications of real- time events is currently being added via the CCR process. Based on discussions with the originator of the RID (Arthur Gaylord), it was agreed upon that an existing requirement (C-MSS-60140) addresses the denial of service attacks. 1.16 Missing Segment Inputs & Outputs Reference: 5.4.1.2 Description: Inputs & outputs to external systems and to SDPS & FOS segments are not sufficiently identified to support design activities. Requirement C-MSS-10410 points to ECS Internal ICDs, however Internal ICDs are preliminary documents. See priority 2 RIDs 2.3, 2.4, 2.5 and PDR RID 281 (Schroeder on External ICDs). Recommendation: In addition to accepting External ICDs as binding as in response to PDR RID 281, recommend Internal ICD (DID 313) be accepted as binding, or add binding interface requirements (i.e., definition of segment inputs and outputs). Since the ECS Internal ICD (DID 313) is now a final document, the new version is now a binding document. Table 2.1-1. ECS Responses to NASA Comments (8 of 22) NASA Comment ECS Response 2. Comments 2.1 GSFC LSM Management Workstations Reference: Section 4.4.2.1 Description: Requirement C-HRD- 42015 suggests that some Management Workstations may not be able to perform some EOC LSM functions. Recommendation: Remove the phrase which can perform any EOC LSM function or specify EOC LSM requirements distinct LSM requirements of other sites. The phrase "which can perform any EOC LSM functions" was inadvertently retained when the requirements were cut and pasted from section 4.4.3. This problem also occurs in sections 4.4.4, 4.4.5, and 4.4.6. The requirements are currently being modified via the CCR process so that "EOC" is replaced by "GSFC" in C-HRD- 42015, "MSFC" in C-HRD-44015, "LaRC" in C- HRD-45015, and "EDC" in C-HRD-46015. Since these will be the only Release A Management Workstations at the respective sites, this no longer suggests that there are some other Management Workstations that cannot perform some of the site's LSM functions. 2.2 MSS ECOM External Inputs & Outputs Reference: Section 5.1.1.1 Description: C-MSS-10010 references external input & output requirements for ECOM which could not be found. Recommendation: Identify ECOM external interface requirements. Ecom external interface requirements are listed as the first two entries in Table 5.1-1. 2.3 MSS External Inputs & Outputs Reference: Section 5.1.1. 1, Table 5.1-1 Description: External interface requirements are not sufficiently defined to support design activities. Recommendation: Add MSS interface requirements for functional behavior and required protocols between MSS and externals for each data item in Table 5. 1-1 (e.g., data push/pull, transmission protocols, email, other types of data formats). Reference available external ICDs. Details of external interface requirements are included in the individual external ICDs. The actual detailed interface requirements are not included in DID 304 since they would duplicate the ICD requirements. References are included in the requirements for all ICDs that were final at the time that DID 304 was written. The actual functionality required to provide the interfaces (e.g., data push/pull, transmission protocols, email, other types of data formats) is listed throughout the MSS, CSS, and ISS sections of DID 304. Table 2.1-1. ECS Responses to NASA Comments (9 of 22) NASA Comment ECS Response 2.4 MSS SDPS Inputs & Outputs Reference: Section 5.1. 1.2, Figure/Table: 5. 1-2 Description: Requirement C-MSS-10200 identifies required data items in Table 5.1-2, however those data items are not defined anywhere else within the document and cannot be precisely related to data items in the CSMS Internal ICD. The MSS interface requirements for an SDPS interface do not indicate which type of CSMS interface it requires (e.g., Management Event Reporting, Application Instrumentation Management Request, Notification Interface, and others referenced in Table 3.3-1 of the ECS CSMS Internal ICD). For example, does Fault data in Table 5. 1-2 include error log files from scheduled file transfers (CSMS Internal ICD page 5-29)? Do performance reports imply requirements for event and log interfaces? Are schedules included in event data, or logs? Recommendation: Define the data items in Table 5. 1-2 using terms consistent across segments (i.e., system- level). Add MSS interface requirements that indicate CSMS interface services (as specified in the CSMS Internal ICD) required for exchange of each data item in Table 5. 1-2. The SDPS interfaces are described in detail in the final version of the CSMS/SDPS Internal ICD (DID 313). In order to avoid duplication, we have not repeated the requirements here. All functionality required to implement these interfaces is listed throughout the MSS, CSS, and ISS sections of DID 304. 2.5 MSS FOS Inputs & Outputs Reference: Section 5. 1. 1.3, Figure/Table: 5.1 -3 Description: Requirement C-MSS-10300 identifies data items in Table 5.1-3, however those data items are not defined within the document and cannot be precisely related to data in the referenced CSMS Internal ICD. The MSS interface requirements for the FOS interface do not indicate the CSMS services required (e.g., Management Event Reporting, Application Instrumentation Management Request, Notification Interface, and others referenced in ECS CSMS Internal ICD). For example, does P&S operational status information in Table 5. 1-3 include management agent log files (CSMS Internal ICD page 4-6)? Recommendation: Define the data items in Table 5. 1-3 using terms consistent across segments (i.e., system-level). Add MSS interface requirements that indicate the specific CSMS interface services (as specified in the CSMS Internal ICD) required for exchange of the data items in Table 5.1-3. The FOS interfaces will be described in detail in the final version of the CSMS/FOS Internal ICD that is currently being developed. In order to avoid duplication, we have not repeated the requirements here. All functionality required to implement these interfaces is listed throughout the MSS, CSS, and ISS sections of DID 304. Table 2.1-1. ECS Responses to NASA Comments (10 of 22) NASA Comment ECS Response 2.6 MSS LSM-EMC Inputs & Outputs Reference: Section 5.1. 1.4, Figure/Table: 5.1-4 Description: Requirement C-MSS- 10400 identifies required data items in Table 5.1-4, however those data items are not defined within the document, do not appear to be described consistently with other segment interfaces data items nor the data descriptions used in the ECS CSMS Internal ICD. Recommendation: Define the data items in Table 5.1-4 using terms consistent across segments (i.e., system-level). Add MSS interface requirements that indicate CSMS interface services (as specified in the CSMS Internal ICD) required for exchange of each data item in Table 5. 1-4. Most of the data items listed in the table are defined and used elsewhere in the MSS section of the document. Because there are several items not defined elsewhere and there may be additional data items that should be added, this table will be updated in the next published version of this document. Individual MSS interface requirements will not be added to DID 304 since they would duplicate requirements listed in the Internal ICD. 2.7 MSS CSS Subsystem Inputs & Outputs Reference: Section 5.1. 1.5, Figure/Table: 5.1 -5 Description: Requirement C-MSS- 10410 identifies required data items in Table 5.1-5, however those data items are not defined within the document, and appear to be services (i.e., not data) described in the ECS CSMS Internal ICD. Recommendation: Identify data items in Table 5 1-5. Associate each data items with CSMS interface services (as specified in the CSMS Internal ICD) required for its exchange. This table identifies CSS services that will be used by MSS. This table will be updated in the next published version of this document to clearly reflect that the MSS interfaces with the CSS to use the listed CSS services. 2.8 SNMP Monitor Service Requirements Reference: Section 5.2.1.2, Figure/Table: 5.2-1 Description. Requirements C-MSS- 16050 through C-MSS- 16070 appear to identify capabilities to exchange information with the Monitor/ControlIF Management Application Service (see CMS Context Diagram 5.2- 1), however requirements for a standard interface or API are missing. Recommendation: Add requirements that identify the protocol(s), SNMP API or other methods for exchange of information between the Monitor/Control Common Management Service and the Monitor/ControlIF Management Application Service. A requirement to specify that the Monitor/ Control Service provides APIs for use by Management Applications is currently being added via the CCR process. Table 2.1-1. ECS Responses to NASA Comments (11 of 22) NASA Comment ECS Response 2.9 SNMP Monitor Service Requirements Reference: Section 5.2.1.2, Figure/Table: 5.2-1 Description: Requirement C-MSS- 16020 & - 16040 identifies capabilities to request & receive management data, however requirements for further analysis and/or making this data available to management application services are missing. Recommendation: Add a requirement that will make management data (i.e., collected data) available to management application services (or if appropriate, explain that this data is made available to Management Applications Services via direct interface to the Management Agent using SNMP). The new requirement being added in response to comment 2.8, taken together with existing requirements C-MSS-16005 and C-MSS- 16010, addresses this comment adequately. 2.10 Defining Action on Receipt of Management Event Reference: Section 5.2.1.1.2, Figure/Table: 5.2-1 Description: C-MSS-16050 appears to be an incomplete description of a capability for defining UNIX commands to be executed upon receipt of a SNMP management event or trap. Recommendation: Modify C-MSS- 16050 to require the capability, using MUI services, for the M&O Staff to define a Unix script, command or application to be executed upon receipt of a SNMP management event or trap. A modification to this requirement, providing the clarification indicated in the comment, is currently being added via the CCR process. 2.11 Discovery Service Requirements Reference: Section 5.2.1.2.2, Figure/Table: 5.2-1 Description: C- MSS-20030 identifies a requirement to report missing occurrences of managed objects but does not indicate an ECS management protocol, or the required destination. Recommendation: Modify C-MSS-20030 to indicate whether the report is required to be a SNMP management event, or sent to the M&O Staff via MUI services. The existing requirement states that missing occurrences of managed objects will be reported. Since all MSS reports are intended to be used by the M&O operators, the ultimate interface in this case would be to the M&O staff. The method by which this information is reported and the protocol used is an implementation issue that is reflected in the MSS design documentation. Therefore, no change has been made to the existing requirement. Table 2.1-1. ECS Responses to NASA Comments (12 of 22) NASA Comment ECS Response 2.12 Sole Source & Missing MUI Requirements Reference: Section 5.2.1.4.2 Description: The MUI requirements appear to be oriented towards HP Openview. Requirements for load/unload/browse vendor MIBs, register/unregister managed objects are closer to management applications than MUI services. Missing MUI requirements include 1) managing user environment profiles and workstation initialization, 2) capabilities to display, overlay, animation & control graphics, 3) creating and executing procedures, 4) managing report formats, electronic & hardcopy output. In addition, C-MSS-12005 indicates the MUI shall be compatible with the ECS management framework but does not provide any information about the compatibility requirements (i.e., what interfaces are needed, what services must be the same). Recommendation: Add the missing MUI requirements. Modify C-MSS- 12005 or separate out requirements to indicate which capabilities apply to management applications and other Common Management Service requirements. The Release A MUI will be as provided by COTS management application packages, with a minimal amount of custom desktop development. Each of the possible COTS packages provides somewhat different capabilities in terms of the four suggested MUI requirements listed in the comment. No specific MUI requirements have been developed in these areas in order that all qualified COTS packages can be considered. The capabilities of these packages in this area will, however, be one of the criteria used in product selection. 2.13 Interface Requirements for Scheduling Backups Reference: Section 5.2.1.6.2 Description: C-MSS- 90190 identifies capabilities to specify frequency, time and type of backups, however does not identify an API or interface requirement (e.g., UNIX script/commands) that can be used by the resource and planning subsystem. Recommendation: Modify C-MSS-90190 to identify the required interface protocol for specifying frequency, time and type of backups. The backup of the management database is done internally and is not scheduled through the resource and planning system. Therefore, no interface requirement is needed in the document. 2.14 Missing Office Automation Tool Formats Reference: Section 5.2.1.7.2 Description: None of the OA Tool requirements identify graphics, text, or worksheet file formats such as ASCII standard, RTF, Postscript, PDF, Excel, GIF, etc. Without acceptance of a minimum set of standard formats, post-operations analysis activities (through use of desktop equipment - PCs, Macs) may encounter significant limitations. Recommendation: Modify OA Tool requirements to identify a minimum set of required standard formats. Requirements identifying the graphics, text, and worksheet file formats are currently in the CCR process to be added to DID 304. Table 2.1-1. ECS Responses to NASA Comments (13 of 22) NASA Comment ECS Response 2.15 Operational Status of Applications Reference: Section 5.2.2.3.2 Description: Fault Management Application service is missing a requirement be able to isolate, locate, and identify faults to the level of applications (see C-MSS-60390). To isolate a fault to the level of software is not sufficient for operations. Recommendation: Modify requirement C-MSS-60390 to include the capability for isolating, locating, and identifying faults to the level of an application or group of applications. Existing requirements C-MSS-60130, C-MSS- 60190, and C-MSS-60200 address the capability indicated in the comment. 2.16 Scheduling Configuration Changes Due to Fault Reference: Section 5.2.2.4.2 Description: C-MSS- 60420 indicates that the Fault Management Application Service interfaces with the Configuration Management Application Service to schedule a change in the configuration of a site, however if such a change can be scheduled there may need to be an interface to the planning subsystem. Recommendation: Explain the rationale for a FMAS interface only with CM for scheduling, or add a cross reference to planning segment requirements. The identified requirement was intended to identify an operational interface. The requirement is currently being modified via the CCR process to clarify its operational nature. 2.17 Measurable Performance Parameters for Applications Reference: Section 5.2.3.1.2 Description: Performance Monitoring requirements define the measurable performance parameters for network components (C-MSS-66080), hosts(C-MSS- 66100), and science algorithms(C-MSS-66310), however the measurable performance parameters are missing for ECS applications (e.g., missing user & data processing response time metrics, DBMS performance metrics). Recommendation: Add a requirements that define the measurable performance metrics for ECS applications, including the DBMS. Performance metrics for ECS applications are currently in the CCR process to be added to DID 304. 2.18 Definition of Measurable Performance Parameters Reference: Section 5.2.3.1.2 Description: Performance Monitoring requirements C-MSS-66140 through -66160 are not sufficiently defined to support design activities. Recommendation: Modify or add requirements that characterize the types and forms of performance data expected from external interfaces during Release A. Requirements for types and forms of performance data expected from external interfaces during Release A are listed in the ICD for each interface. Level 4 requirements have not been written in order to avoid duplication. Table 2.1-1. ECS Responses to NASA Comments (14 of 22) NASA Comment ECS Response 2.19 Missing Workload Performance Analysis Reference: Section 5.2.3 Description: Performance Monitoring, Analysis, Trending, Reporting, Testing requirements do not include the capability to provide workload performance analysis. Recommendation: Add requirements to include identification & display of workload transactions (i.e., sets of processes/threads of managed objects with measured or estimated response times) that lead to generation of user data & products. Workload performance management was not included in these requirements since analysis of system data is a Release B requirement according to the release plan. 2.20 User Registration & Security Context Diagram Reference: Section 5.2.4.1.1, Figure/Table: 5.2-4 Description: User Registration is included in Security Management Application Service for IR-1 and in Accounting & Accountability Application Service in Release A, however Reference 5.2.4 does not indicate whether the context diagram is valid for both, IR- 1, or Release A. Recommendation: Provide context diagram for IR-1 and Release A. The document will be updated to reflect the inclusion of this comment in the next version. 2.21 Access privileges for groups of resources Reference: Section 5.2.4.2.2 Description: C-MSS- 70110 identifies a capability to specify access privileges for user groups, however a capability is needed to enable specification of privileges for groups of resources. Recommendation: Modify C-MSS-70110 or add a requirement to enable specification of privileges for groups of resources. Access privileges for individual resources provides more granularity than access privileges for groups of resources. The number of resources in Release A will be small enough that specifying privileges for groups of resources is not necessary. As the number of resources increases in Release B, however, the indicated requirement may become desirable and may be added. 2.22 User Account Integrity Reference: Section 5.2.5.1.2 Description: C-MSS-75020 indicates new user account are created by adding records to the user profile database, however requirements are missing for capabilities to manage access (e.g., lock/update records) the user profile database. Recommendation: Add requirements for capabilities to manage the user profile database. Add requirements to enable addition of fields to the user profile database. Indicate whether the user profile database is included as part of the management DBMS. Identify schema and relationship with user database in SDPS segment. The existing requirement C-MSS-75000 addresses the management of the user profile database. The user profile has a standard definition since it is used by subsystems at all sites. The requirement reflects a baseline for Release A. Although it is possible that additional fields may be added to the user profile through a formal process for Release A and beyond, it is felt that the capability for dynamic addition of fields (as suggested in the comment) to the user profile database should not be supported. The physical mapping of the user profile database to data stores is a design issue that is addressed in the documentation of the Critical Design Review. Table 2.1-1. ECS Responses to NASA Comments (15 of 22) NASA Comment ECS Response 2.23 Accountability Management Service Requirements to Interface with Management Agent Services Reference: Section 5.2.5.1.2, Figure/Table: 5.2-5 Description: Missing requirements to receive user profile request, order status request, and account history request from Management Agent Services. Missing requirements to provide user profile information, order status information and account history information to Management Agent Services. Recommendation: Add or modify requirements to show capability for exchange of accounting information through Management Agent Services. A requirement for receiving requests for the user profile is currently being added via a CCR process. The Client subsystem design for Release A does not require that MSS support requests for order status data or account history data. These requirements are being deferred to Release B via the CCR process. Requirements for the support of the retrieval of order status data and account history data from the Management Database by M&O Staff are currently being added via the CCR process. 2.24 User & Data Audit Relation to Baseline Reference: Section 5.2.5.2.2, 5.2.5.3.2 Description: C-MSS-76000 and -77000 include user activity & data processing activity from SDPS subsystems, however these need to be related to elements (managed resources) within those subsystems for accountability (SMC-6335). Recommendation: Add requirements for capabilities to report user activity & data processing activity for each managed resource. A requirement for the reporting of user activity by ECS managed service is currently being added via the CCR process. A requirement for the reporting of data processing activity (product generation) by ECS managed resource is currently being added via the CCR process. 2.25 Missing Management Agent Exception Handling Reference: Section 5.4.1.2 Description: The MSS Management Agent Service requirements indicate there will be several types of management agents, however there are no requirements for handling exceptions (i.e., errors or faults) in a standard or conventional way for specific types of ECS applications (e.g., DBMS, file servers). Recommendation: Add requirements for exception handling standards or conventions. DID 304 specifies requirements for the agent to be able to log events and to send traps to the Monitor/Control service. This provides the capabilities necessary for handling exceptions. The actual methods of implementing exception handling are part of the MSS design and as such are described in the design document. 2.26. Clarify meaning of a "Limited" C++ Interface Reference: Section 6.4.2, C-CSS-01000 Description: The requirement specifies a mapping to "C++ (limited)". Will these limitations limit the use of C++ as an implementation language for ECS? How will this limitation affect inheritance and object use? Recommendation: Clarify the limitations implied by the use of the word "limited". Specify how these limitations will limit the use of C++ as an implementation language. Limited C++ language bindings here mean that the objects defined in the Interface Definition Language (IDL++) (also called distributed objects) do not support interface inheritance and attributes. Other than that it doesn't limit the use of C++ as an implementation language in ECS. The text around the requirement will be updated in the next revision to the document to clarify the requirement text. Table 2.1-1. ECS Responses to NASA Comments (16 of 22) NASA Comment ECS Response 2.27 Clarify requirement for unitary login Reference: Section 6.3.3.2 Description: Is unitary login, that is only requesting a user's password once for access to multiple ECS services, a requirement? It appears, based on the discussion, that this is intended. However, it is not clear that the requirements as stated require a unitary login. Recommendation: Clarify the requirements regarding unitary login. Unitary login is not a requirement, but is part of the CSS Security Service design for Release A. Therefore, no actual addition or modification of requirements is necessary. As a clarification, unitary login refers only to the number of logins required for access to ECS services. The user first must login to the local workstation before logging into ECS. 2.28. Remove or isolate design discussion from text Reference: Section 6.3.7.1, fourth through sixth paragraphs Description: The discussion in these paragraphs seem to reflect the design of the threads facility and not the requirements. As such, this discussion appears out of context. Recommendation: Move this discussion to the design specification. The intention here is to provide a description and set the context before presenting the requirements. This format has been followed for all the services with in CSS and for all subsystems in ECS for the requirements document. 2.29 Additional references should be included Reference: Section 2 Description: References do not appear to other communications documents that may be relevant to the CSMS concept, such as DCE and CORBA. Recommendation: Add the relevant references. Review the Abbreviations and Acronyms for items that should be covered by the references. Additional references to DCE and CORBA will be included in the next update to this document (including updating the Abbreviations and Acronyms). 2.30 Mail Service versus MailTool Requirement should be moved Reference: Section 6.2.1.2, C-CSS-61290 Description: Requirement C-CSS-6 1290 is classified as a general mail service requirement as opposed to a MailTool requirement. Recommendation: Either reclassify this as a MailTool requirement or add an API requirement to allow non-interactive programs to use this facility. Requirement C-CSS-61290 will be moved to the MailTool section in the next update to this document. 2.31 Bulletin Board Requirements Model should accommodate recent technologies Reference: Section 6.2.3 Description: It appears that the bulletin board requirements are based on the model for Internet newsgroups. There is an alternate model based on the World Wide Web (WWW) or Mosaic capabilities that have recently become available on Internet. This model would provide for significantly enhanced capabilities over the newsgroup model. Recommendation: Modify the requirements in this section to accommodate to the WWW model, rather than the Internet newsgroup model. CSS is providing both Bulletin Board and the World Wide Web capabilities. This clarification will be made in the supporting text in the next update to this document. Table 2.1-1. ECS Responses to NASA Comments (17 of 22) NASA Comment ECS Response 2.32 Event Logger Service Requirements Reference: CSMS Requirements Spec. Description: The following is taken from PDR RID 200 submitted against the Preliminary version of this document. The RID response indicated that the document was corrected; however, issues from the originators recommendations were left uncorrected. C-CSS-28000 - Logger service should support logging to multiple, application specified, log files. Recommendation: Consider and revise requirement. CSS Design DID 305 Volume 12 reflects this new feature of logging to application specified log files (in addition to the management log files). The text around the requirement will be updated in the next version of the document to clarify this requirement as recommended. 1. Major Comments 1.1 Level 4 requirements, in general, do not cover the functionality of each of the Level 3 requirements in sufficient level of details. In some cases, Level 4 requirements cover only the partial functionality of level 3 requirements. This is a duplicate of Comment 1 above. The response is addressed there. 1.2 Level 4 functional requirements are incomplete. For example; Level 4 requirements do not exist for the following Level 3 ESN functional requirements: ESN-0700 The ESN management architecture shall be consistent with architecture defined in OSI management framework (ISO 7498-4) and OSI System Management Overview (ISO DIS 10040) ESN- 1330 The ESN shall provide ISO/OSI data communication protocols and services specified in the GOSSIP to external interfaces as required by IRDs ESN-1367 IST users not within FOS facilities shall communicate with secure interfaces only with the use of a data integrity service This is a duplicate of Comment 2 above. The response is addressed there. 1.3 The traceability of the following level 3 requirements is missing in Level 3 to Level 4 requirements traceability matrix in Appendix D. ESN-0345 The ESN shall interoperate and exchange messages and data with external SMTP and X.400 mail system ESN-0350 The Electronic Messaging service shall be capable of transparently transmitting MIME messages ESN- 1365 The ESN shall isolate FOS with secure interfaces This is a duplicate of Comment 3 above. The response is addressed there. Table 2.1-1. ECS Responses to NASA Comments (18 of 22) NASA Comment ECS Response 1.4 No detailed explanation has been given for the preliminary SDPS Network data flow sizing estimates provided in Appendix A (Tables A-5 and A-6). The tables contain few TBDs. In order to verify the data flow sizing estimates, it is very important to know as to how these numbers were derived from the technical baseline. This is a duplicate of Comment 4 above. The response is addressed there. 1.5 Level 3 to Level 4 requirements traceability needs to be checked very thoroughly to make sure that level 3 functional requirements are covered by the Level 4 requirements in sufficient details. This is a duplicate of Comment 5 above. The response is addressed there. 2. Other Comments: 2.1 Section 3.3 (Page 3-3) To be consistent with other CSMS subsystems, provide a ISS subsystem diagram. A context diagram will be provided in the next update to the document in accordance with this comment. 2.2 Table 3.4-1 (Page 3-6) Service class mapping to CSMS CIs not shown by release IR-I and release A List of service classes specified in Figure 3-2 and Table 3.4-1 do not match. Service superclass for ISS should be specified as "Network" instead of "Transport", "Network", and "Data Link/Physical" as specified in 307-CD-003-002 (Page 4-2) "Naming" service should be specified as "Directory/Naming" in this table and throughout the document. The next published version of the document will be corrected to reflect these comments. 2.3 Section 3.4, Para 4 (Page 3-5) Internetworking hardware CI (INHCI) should also include the protocol translation and bridging devices. The referenced paragraph is editorial text that was included for the sake of clarification. There is no requirement to support protocol translation (e.g. DECnet to SNA) within the ECS network. 2.4 Section 4.3.2.1, Requirement No. C-HRD-31000 (Page 4-25) Release A sites are listed as LANs instead of sites This is a typographical error. The site names will be corrected in the next published version of this document. 2.5 Requirement C-HRD-36100 (Page 4-27) Explain how 48 Mbps data rate for EOC operation LAN was derived. There is no requirement for EDC DAAC LAN Based on data flow sizing analysis the EOC operational LAN is estimated to carry a peak traffic load of 24 Mbps. In order to allow for 100% expandability without redesign, this traffic load has been multiplied by 2. This results in the quoted 48 Mbps peak load. Table 2.1-1. ECS Responses to NASA Comments (19 of 22) NASA Comment ECS Response 2.6 Table 7-1 (Page 7-3) Network provider interface for V0 systems at GSFC and MSFC should be GSFC V0 DAAC LAN and MSFC DAAC LAN respectively. Specify EOC LAN as EOC operation LAN or EOC support LAN to avoid confusion Include local SCFs as external end systems for connectivity to GSFC campus network This is a typographical error. The entries in the Network Provider Interface column in Table 7-1 will be corrected in the next published version of this document to list the correct interface provider. The term EOC LAN is used generically to mean both the EOC operational LAN as well as the EOC support LAN. The operational LAN is to be used for critical real-time functions with an availability of 0.99980. The support LAN has less stringent requirements. The exact context will be clarified in the text surrounding the requirements in the next published version of this document. Local SCFs are included in the external users located on the GSFC Campus Network. However, the sentence, "Color, external users located on the GSFC Campus Network" in Table 7-1, will be modified in the next published version of this document to read "Color, external users located on the GSFC Campus Network, including SCFs" for consistency. 2.7 Section 7.1.1.4 (Page 7-2) Requirement for LAN connectivity and OSI layer 1 through 4 services between CSMS and SDPS components at GSFC DAAC, between EDC DAAC and CSMS components, and between the SMC and other DAACs are missing. Requirements # C-ISS-01300 and C-ISS-01320 are in duplicate. The missing requirements are currently being added via the CCR process. Duplicate requirement C-ISS-01320 is currently being deleted via the CCR process. 2.8 Section 7.1.3 (Page 7-7) Specify EOC LAN as EOC operation LAN or EOC support LAN in Requirement # C-ISS-04040 Portions of the same DAAC LAN supporting different functions and satisfying different RMA requirements is not clear. The term EOC LAN is used generically to mean both the EOC operational LAN as well as the EOC support LAN. The operational LAN is to be used for critical real-time functions with an availability of 0.99980. The support LAN has less stringent requirements. Requirement C- ISS-04040 is currently being modified via the CCR process to specify the correct context. Operational availability and MDT numbers are allocated to DAAC LAN functions that support various SDPS services. Such allocation is necessary in order to specify the RMA for the entire LAN Table 2.1-1. ECS Responses to NASA Comments (20 of 22) NASA Comment ECS Response 2.9 Section 7.2 (Page 7-9) Level 4 requirement for ISS's SNMP support is missing. ESN-0740 level 3 requirement states that ESN management service shall retrieve performance/fault data about ESN protocol stacks and equipment. There is a Release A level-4 requirement (C- HRD-32010) that specifies the capability to monitor ISS physical components, and services via SNMP agents. Attachment C Document Title: ECS CSMS Requirements Specification Document These comments are on the Communications and System Management Segment (CSMS) Requirements Specification for the ECS Project Final document dated March 1995. The comments have been separated into the two categories of "content" and "editing". The attempt has been made to indicate comments concerning the topics addressed and their expression in the "content" category while placing comments on wording, sentence structure, and so forth in the "editing" category. Content Page 5-4, Table 5.1-1: EDOS has no requirements to exchange the listed Authentication data, Schedule Data, nor Security Breach Notification data with the ECS. The table will be corrected to indicate "Operations Management Data," as listed in the IRD. Page C-2, Table C-1, IRD to Level 4 Traceability by Release: The "IRD Requirement ID" and "IRD Text" table entries do not match either the requirement numbers nor the text in the EDOS-EGS IRD document referenced as a Parent Document on page 2-1. Please revise the traceability matrix to match the IRD. The numbers in the traceability matrix are direct outputs of the EDOS-EGS IRD as loaded into RTM (apparently from a previous version). A CCR to correct the IRD requirement numbers and text in the RTM database and to revise the tracing to level 4 requirements is being processed. Editing Page 2-4, entry for RFC 1522: The word for "multipurpose" is misspelled. The next published version of the document will be corrected to reflect the correct spelling. Andy Germain.4/20/95 5:40 AM, Comments on CSMS PDR docs Table 2.1-1. ECS Responses to NASA Comments (21 of 22) NASA Comment ECS Response 1) Completeness First, I am concerned over the level of detail contained in the requirements spec. The concern is based on the principle that at some point, the requirements must be expressed to a level of detail such that we can be sure that the system will be acceptable if it meets its requirements. It is clear that the level 3 requirements are not at this detail level. The level 4s expressed here are the final level to be developed. and it appears that they are still quite general. I believe that in general, they are a reasonable expansion of the level 3s. However, in an apparent desire to avoid unnecessary constraints on the ECS implementation, the final level of detail is not included. This could easily result in a system which meets the stated requirements, but does not perform satisfactorily. Likewise, the CSMS Integration and test plan contains only the top level functionality of each element. Important details such as test of error handling and retries are not generally considered. Like the requirements the tests focus on the basic capabilities only, and not the detailed functionality. If this is not the place for the full detailed requirements, I am not sure what is. See response to Comment 1. 2) Enterprise Management The enterprise management concept seems substantially missing from the requirements and design documentation. While an SMC exists, performing the Enterprise Management Functions, the concept of a coordinated management information resource seems absent. While the enterprise management capabilities are provided in the functionality described within these requirements (i.e., roll-up of management data into the SMC management database for system-level analysis), the use of the capabilities to perform enterprise management capabilities may not always be clear. Other documents, such as the Design Document and the Operational Concepts Document provide a clearer description of these capabilities. 3) ISS I believe the ISS requirements (baseline) are fairly well understood, and this is not a major area of concern. However, note that the results of the Network Backbone Team are likely to cause major changes in this area. We agree with this assessment and are aware of the consolidation efforts related to the ESN, ECOM and PSCN. However, the PDR version of DID 304 was written well before the network consolidation activities got started. Any changes resulting from the backbone network consolidation effort will be evaluated and incorporated into the requirements document if necessary. Table 2.1-1. ECS Responses to NASA Comments (22 of 22) NASA Comment ECS Response 4) some details and examples a) Req Spec section 5.1 .1.1 (MSS External Interface) What about Ecom faults, performance. etc.? b) I&T Plan (IR-I) section 4.3 (Security) What about intrusion detection The interface data provided is as listed in the referenced IRD. More data on the information provided by this interface will be provided in the ICD currently under development. The requirement will be updated to reference the ICD once it becomes available. Comments for the I&T Plan should be addressed separately.