Issue

Issues List

Go to Issue Number:
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13,
14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24

Go to Open Issues - Go to Closed Issues - Return to SWSI Home Page

Issue No.	Title	Originator	Description
1	Openness of SWSI Scheduling Parameters	Riley Elwood	MOC operators should not be allowed to respecify parameters to avoid possibility of human error.
2	Bulk Schedule Retransmission	Riley Elwood	What method will be used via SWSI to cancel/retrans all confirmed NCC schedules for a particular SIC? Would this have to be handled at the client level (MOC)-at worst one-by-one?, or can this be handled within the SN only, between the SWSI servers and the NCCDS operators, on behalf of the MOC?
3	Scheduling of Bulk Transmissions	Riley Elwood	The NCC requests/cues users when to cancel/retrans on a one-by-one customer basis to insure the NCCDS interface is not overloaded with everyone doing it at the same time (and help with the priority of things). Is it envisioned that the SWSI servers could be subject to this same type of total loading concern either with the client/server interface or the server/NCCDS interface
4	SWSI Validity Checks	Riley Elwood Howard Michelsen	SHO, GCMR validity checks (of actual parameter values or proper message use for the operational situation) are shared on the SN between the NCCDS and WSC ADPE, so as not to duplicate SW efforts (efficiency of the end-to-end system). It was not clearly shown at the R/DR exactly what SHO, GCMR validity checks would be performed by the SWSI prior to client transmission. Its understood at the R/DR that SWSI would essentially use the NCCDS validity checks to advise the customer of any rejections at time of submission. However, not all checks are completed immediately. Essentially, when the final message reaches WSC and is accepted for implementation then the entire end-to-end function is completed (i.e., SHO service reservation is generally 24 hrs ahead of time, and/or in the case of GCMR's its done in real time during support). Will the SWSI interface handle all aspects of message rejections (from NCCDS as well as WSC?) whether in real time, near real time, or perhaps days later in the case of SHO's?
5	Pre-Canned GCMRs	Riley Elwood Howard Michelsen	I did not see in the SWSI design a capability within the MOC client SW to build and save several pre-canned GCMR configurations, such to allow rapid transmission of several messages, if needed.
6	Password Lockout	Buck Buchanan	Having no timeout on the password lockout denies the user access until they get some one to unlock the account. I would suggest that you have a lockout period of 30 to 60 minutes on failed login attempts.
7	User Timeout Lockout	Buck Buchanan	I understand the need for having no timeout on logins, but I would like to have added to the client software an option for the user to lock the application and to automatically lock the application after some amount of time with no user input (keystrokes or mouse).
8	Password Encryption	Buck Buchanan	In regards to how the passwords are stored in the database, they should be hashed with something like MD5 or stronger. The password file should be encrypted. By storing password hashes rather than the clear text password, the encryption key for the password file no longer needs critical protection.
9	Use of Rijndael Encryption Algorithm	Matt Kirichok	SSL3 will be used for data encryption. When will the use of the Rijndael algorithm be used, since this is the latest approved encryption algorithm for use within the US Government?
10	Encryption through IOnet Secure Gateway	Matt Kirichok	It is mentioned that three (3) socket connections will be made through the NISN Secure Gateway and that these will be encrypted. This is NOT allowed through the Secure Gateway.
11	Number of RAID Disks	John Gasch	The hardware architecture shows that Oracle will reside on a single RAID. If the database will be in "archive log" mode, Oracle needs at least two disk independent disk drives to house the mirrored redo-logs and control files. It would be strongly advisable to have the archive log files written to a third independent drive. If performance is an issue, then you need at least 4 independent drives so the base tables and indexes can be segregated.
12	RAID Reliability	John Gasch	Relying on a shared RAID for failover redundancy is risky! It has been my experience that RAID reliability is questionable, especially when hosting a database. The database application will thrash the disks hard. On three separate occasions between the XTE and TRMM MOCs, hard RAID failures were unrecoverable, resulting in a total loss of data since the last tape backup. Both missions have abandoned their RAIDs. Oracle databases can be run in "hot standby" mode wherein the database on the backup server is maintained as a clone of the primary database. A complete loss of the primary database - disks and all - results in no lost transactions.
13	Use of Flat Files for Data Storage	John Gasch	I am puzzled by the need for the "local flat file storage" between the Isolator and the SNIF. Why can't this data be stored in the database and eliminate the need to handle and manage separate flat files. Where are the flat files stored? Will they be preserved following a failover? This appears to me to be a potential source of inconsistency between the data in the flat files and the corresponding records in the database.
14	Alert Retrieval from Server	Doug Spiegel	If we lose connection to the server, will we get the missed alerts (are they stored on the server as well)?
15	Automatic Client Reconnection	Doug Spiegel	If there is a server failover, TCP conn needs to be re-established, does this mean the MOC client must log in again? If this occurs during un-staffed periods in the MOC, then the MOC won't login again until next shift - what's the mechanism to obtain the missed data (UPD, alerts, etc)?
16	Orbital View (TSW) Verification	Howard Michelsen	Any mission that desires a TDRS contact for approx. the duration of the TSW will need to ensure that their antenna is in view of a TDRS. While some of the misions targeted to use SWSI plan to have contacts shorter than their TSWs, others, such as LDBP may not. To verify that a schedule request is within a TSW requires human calculation "drudgery", which, it appears to me, is what computers should be doing.
17	TUT Window Verification	Howard Michelsen	Verification should be provided to user that spacecraft is in view for a given TUT period, or that only TUT periods that are within view should be supplied.
18	Flexible Scheduling and Recurrent Schedule Request Creation	Howard Michelsen	Although SWSI supports the flexible schedule message format, it has been our experience that to actually make use of the flexible capabilities is far too arduous for human calculation. For example, although the UPS supports a user creating a single flexible SAR, we have found that, in practice, only Recurrent Scheduling can be effectively used to create a flexible SAR that takes full advantage of the flexibilities offered. To attempt to calculate the service tolerances, minimum durations, coupling, and bounding, while matching each service duration to the service's TSW duration, and applying these to the TSWs of multiple TDRS's (in a TDRS Set) rises beyond most users pain tolerance. Then imagine doing this feat for, even in a simplistic case, one contact per day!
19	Graphical Displays	Howard Michelsen	Graphical display of schedule request, TSW, TUT is desirable. Although SWSI is targeted toward low-usage customers, it is nevertheless highly desirable to graphically view a schedule request in context of a TSW or, particularly in the case of DAS users, a TSW filtered by the applicable TUTs.
20	Application Security Patches	James Blunt	Security Patches, page 35: O/S is mentioned, but not applications [e.g., Oracle]. I know the section is "System Level Security" but patch control should be at a fairly high level]
21	Privileged Level Activity Logging	James Blunt	Application Server Logging, page 57: User activity is mentioned, but not administrator and other privileged level activities. [You may be assuming that higher levels are included]
22	Automation for Unattended MOCs	Steve Thompkins	SWSI has been baselined as the user's interface to DAS. SWSI is intended to be used by a person. However, of the four potential DAS users that I know of (Swift, GLAST, Aqua, and GPM), only Aqua will have a full time staff. The others will be staffed on prime shift only. They would have some relatively simple automation to handle routine tasks when the Mission Ops Center is unstaffed. I don't see any easy way to connect the automated MOC system to SWSI.
23	DBA Interface	Tom Sardella	There is no DBA interface defined for maintaining system configuration tables.
24	Shuttle Support	Riley Elwood	JSC has expressed a desire to move away from using a dedicated UPS system. One possibility would be to incorporated UPS capability into SWSI and switch to using SWSI. The problem is that SWSI is not currently designed to support Shuttle-unique services.