Question 1:  On the NCCDS-MOC Interface diagram found in the review handout on page 9: It was noted that two message types were missing; the schedule result request and UPD (User Performance Data Request) messages were not found on the diagram.
Response:  They were left off since they are automatically sent during initial startup.

Question 2:  Why did we choose UDP to be the protocol between the Isolator and SNIF?
Response:  It is a simple protocol and since the Isolator and SNIF are located on the same machine and all data transmitted between them can be recovered, reliability is not a factor.

Question 3:  Explain the connection between the Isolator and SNIF; particularly, how does SWSI handle database update by both the Isolator and SNIF systems.
Response:  Oracle will handle the data synchronization and record locking to ensure no data is lost.

Question 4:  Is the Webserver included in the COTS listing to replace the current TUT Server?
Response:  No the Webserver/"new"TUT server is in addition to the current server. The current TUT Server only handles users on the closed IONET. The new server will handle users on the open IONET.

**
Question 5:  How many concurrent people can connect to SWSI? How expandable is the SWSI Architecture? Can the current design support the DAS requirement to support 50 concurrent users?
Response:  We have designed the Architecture to be expandable. We can add more machines for processing power if necessary and put the DB server on a separate machine from the Isolator and SNIF subsystems. We can also move the SNIF subsystem to its own machine if necessary and change the protocol between the SNIF and Isolator to TCP. The software is being designed to handle an unlimited number of users.

**
Question 6:  Will SWSI be able to support automatic tracking for up to 50 space crafts.
Response: We will need to perform rigorous performance testing after the initial build so that we can more accurately predict SWSI load values. The SWSI system is being designed to be scalable so that it can accommodate a number of concurrent users. The Jswitch system, which the SWSI is using for its backbone, was performance tested with 12 concurrent users.

Question 7:  Are both the backup and primary servers processing simultaneously or is only the primary server processing and the backup system is strictly for fail over purposes?
Response:  The backup server is sitting in background mode and will only process when the primary server fails/fails over to the backup server.

Question 8:  Does SWSI have a user response time requirement (mainly concerned with UPD data)?
Response:  No, but we are trying to design for optimal performance. We feel with the current design UPD data should be received by the client within a couple of seconds.

Question 9:  What is the TCP connection between the open and closed sides?
Response:  It is a custom built. No FTP will be allowed.

Question 10:  Is the connection a push from the open to the closed side or a pull from the closed side to the open side?
Response:  The connection is initiated from the closed side.

Question 11: Isn’t the text going through the NISN firewall supposed to be clear text instead of encrypted text?
Response:  The SWSI team has not seen any document requiring the text to be clear text; however it was noted that the preference is clear text.

Question 12: Will the passwords stored in the database be clear text or encrypted?
Response:  SWSI passwords will be stored encrypted.

**
Question 13:  Where will the keys for encryption be stored?
Response:  The keys will be kept in the database. This issue needs to be further discussed.

Question 14:  Will the user be automatically prompted to change a password after a set number of days?
Response:  Yes, a user with an expired password will be prompted with a change password panel. The user will not be able to login to the SWSI server until the expired password has been changed.

**
Question 15: Who will be responsible to perform administrative functions. For example to add new users, etc.
Response:  This responsibility has not yet been defined, but will probably be the responsibility of a NCC system administrator.

Question 16:  Are any validations of schedule requests being performed against the TSW?
Response:  No, NCC will perform the validation.

Question 17:  Will the client be timed out for inactivity.
Response: No.

**
Question 18:  Can the Alert Panel retrieve Alerts from the client Alert log?
Response: No, this is not part of the current design. The alert file is ASCII based and can be viewed by a user on the client machine. Retrieving alerts that are stored in the database will be added in the future release.

Question 19:  Is it possible for an Alert to be dropped?
Response:  No, alerts are kept in the database and are also stored in an alert log file (a flat file) on the client machine. Users can view the flat file as they please.

**
Question 20:  Is a timeline going to be added to the Schedule Add Request Panel? If it is not, are we not going technologically backwards with SWSI?
Response:  A timeline will be taken into consideration for future releases of SWSI.

Question 21:  What are the "Move Up" and "Move Down" buttons for on the Schedule Add Request Panel?
Response:  To allow the user to reorder the services since the ICD mandates that services be in a particular order for a SAR. The reordering is considered a user procedure and will be documented as such.

**
Question 22:  If the NCC system goes down, what happens to Schedule Requests? Must the entire request be resubmitted?
Response:  This issue must be taken into further consideration. SWSI must consider implementing a backup capability to resubmit/transmit schedule requests. Currently, the schedule request data will have been stored into the SWSI database prior to the loss of the NCC connection. Nothing has been designed to retransmit the schedule request data to the NCC in cause of an NCC failure.

**
Question 23:  Is any type of validation/cross validation being performed on the SAR flexibility parameters? (Ex. make sure that a coupled service isn’t coupled to itself).
Response:  Minimal validation will occur on the Respecifiable Parameters panel. SWSI doesn’t want to duplicate NCC validations. The NCC will perform validations and will reject invalid entries. This issue needs to be further discussed.

Question 24:   Can the Respecifiable Parameters panel be tailored or is it generic?
Response:  The user cannot modify the selections provided on this panel. The Respecifiable Parameters Panel layout is maintained in the SWSI database. Updates to the Respecifiable Parameters Panel will be made by updating the SWSI database. When a user logs into the SWSI system, the Respecifiable Parameters Panel layout, including any updates, will be sent to the user.

Question 25:  Will the WLR ensure a SAR was declined?
Response:  Yes.

**
Question 26: Has a comparison of the fields on the Active Panel and the Schedule Requests Panel been performed?
Response:  No, these panels were only compared to their NCC counterparts. The fields on the Active Panel and Schedule Requests Panel will be compared so that the same fields are labeled the same.

Question 27: Are declined requests shown in the Active Schedule Panel? (It would be helpful, because the replacement request is generated from the Active Schedule Panel).
Response:  No, declined requests are only displayed on the Schedule Request Panel and an alert will be sent to the alert panel.

Question 28:  Why is the service type/SUPIDEN/TDRS ID not pre-filled on the GCMR Menu Panel when the GCMR Menu is accessed from the Main Panel?
Response:  This data is not easily accessible when accessing the GCMR Menu Panel from the Main Panel.

Additional Notes:  The option to do GCMR from the main panel is for the events that may not be in the SWSI database for some reason or other, hence service type/SUPIDEN/TDRS ID is not available.

Question 29: Where is the server activity logged?
Response:  In a flat file stored on the server machine.

**
Question 30:  Does the SWSI design include implementation of a SWSI Administrative tool?
Response: No, it may be considered for a future build.

Comment 1:  On slide 27, Server Hardware, the 9MB should be 9GB.

**  Questions needing further discussion.