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.