Draft Information Gathering and Problem Solving paper							Concepts and Strategy concerning e-mail,

[To be used as background for related issuances such as Records and Archive Management of E-mail RAM/1996-281] 

Table of Contents:
1.	Introduction [and Philosophical perspective]

2. 	Technical Basics(see also Annex E):

3.	Storage automatic selection [See also Annex B & D]:

4.	USE/User: transmission/Record keeping:

5.	Time for adjustment/training [See also Annex A & C] 

6.	Total Cost & automation Process [See also Annex K]

7.	Para to be added based on feedback [See Annex L & M]

8.	Appraisal:  Financial Rules and "Appraisal GRID"

See List of Annexes on Following page:

ANNEXES related to E-mail

Annex A: 	User Concerns with Implementation
Annex B:	Future issues of E-mail [CC:MAIL/Notes mail?]
Annex C 	Recent common Questions related to E-MAIL
c.1.	Electronic copy "cc:mail" considered a record copy.
C.2.	Migration to future e-mail and legacy data.
c.3.	Disk space, alternatives to print records, budget?
c.4.	Electronic subject files; printed copies or neither?
c.5. 	Delete or "move messages
c.6.	Rules for on-line,"near‑line" or "off‑line"?
c.7. 	How long records kept off‑line or near line.
c.8.	Impetus for moving messages and user C drive Backup?
Annex D:	Back up schedule & Disaster Recovery Plan
Annex E:	Reference to further technical information
Annex F:	Appraisal GRID for decision of Retention/Destruction
Annex G:	Appraisal Grid and E-mail Categories or Samples
Annex H:	Discussions/consultation on move/delete of users files:
Annex J:	Related papers of Interest:
j.1.	CF/IRM/1996-??? Information Management Discussion Note [Draft 30 Oct 96]
j.2.	CF/EXD/1996-015 Use of Electronic Mail 03 Oct 1996
j.3	UN/ST/AI/386 Electronic Mail Policies and Standards 23 Aug 1993 [RAM/1996-299]
j.4	CF/IRM/IP/1996‑066 "Electronic Discussion Databases/Document Conferencing"
j.5	CF/IRM/IP/1996‑067 "Selection of a Document Repository Software Tool"
j.6	CF/IRM/IP/1996‑068 "Submission of Documents for the UNICEF Central Electric Document Repository"
j.7	UN/ACC/1996/ISCC/6 Interim Report of the Task force on Document Management Technology [02 Sep 1996]{RAM/1996-295}
j.8	UN/ACC/1996/ISCC/6/Anx001 Report of the Consultant for the Task force on Document Management Technology [02 Sep 1996]{RAM/1996-294}
j.9	CF/IRM/RAM/1996-320 Users Guide for Off Site Backup Storage Service for Electronic Media  used by UN offices for emergency purposes. Memo from Information Security Unit, Elec Services Div, OCSS, DAM [15 July 1996]

Annex K:	Cost of Disk Space Comparisons
k.1	1-2 Year Previous, Now, 1-2 year Projection
k.2	Disk space vs Volumes/types of Messages
k.3	Disk Space Compared to other costs [Consultants]
Annex L:	Short List Electronic Archive Guideline
Annex M:	3 points to be addressed related to Electronic Archive Guideline
Annex N:	Draft DB Tables for Tracking Backups.
N.1 	AM_BAK01.DB =	System type Identification General, hardware box, application types, etc.
N.2	AM_BAK02.db =	Backup specific types, frequency, generations, exceptions 
N.2	AM_BAK03.db =	Frequency Type, description

---------------------------------------------------------
Details for discussion:
Concepts and Strategy concerning e-mail

1. 	Introduction [and philosophical perspective]:

This information circular is a follow up to CF/EXD/1996-015 of 03 October 1996 Use of Electronic Mail .  It is has been influenced in part by the feedback already received from that Executive Directive, the recent experience at headquarters with CC mail migration to version 6 and our desire to provide users with more of our short and long term strategy.  The executive directive included paragraphs on the importance, privileges ,appropriate uses, security and filing of E-mail. We wish to encourage further thought and hope that these details might assist a better understanding of E-mail use and constraints.	E-mail is both a shared tool and resource.  There are some limitations based on choices and technical capabilities. All of our issuances in this area will be reviewed by a user representative panel.

1.a	It is also important to note, as set out in UNICEF and United Nations policy, All records [including those transmitted via e-mail] must be protected and preserved for reuse irrespective of the medium of creation, transmittal or storage.  Managers continue to be responsible for the records under their control until such time as they officially transfer them to a storage site or device under the intellectual or physical control of the Records Management Unit or UN Archives. 

1.b	In para 6.02 of EXD/1996-015, it is stated that for the time being, CC:MAIL is considered as part of the Personal Information Management environment of staff and do not constitute the official records of the organization.  However, we recognize that for some work units the E-mail system has become [in part] the defacto record keeping system.  Therefore, we must consider the potential problem with this development and note our current limitations in solving them. Government agencies and other organizations which contribute/cooperate with UNICEF facing similar dilemmas. For example, over a year ago the US Supreme Court took the decision that Agencies can not delete messages with the excuse that they could not manage the problem..  

1.c	During the last review of IRM by outside consultants, which included input from other knowledgeable individuals, UNICEF was advised that disk space cost was no longer [and could not be] an overriding issue if we were planning to use electronic items to improve efficiency and speed of communication. Especially for those records of limited life [less than ten years] we need to provide easy secure access without demanding print outs of paper copies. 

1.d	We ideally want to be able to store/archive/retrieve records or documents irrespective of media of creation/ transmission/ storage. That means correspondence, faxes, reports or emails which contain information should be able to be stored in the same electronic folders.  Our long-term strategy is to obtain a package with archival functionality that integrates well with our standard suite of office automation tools ‑ as well as store/retrieve multiple types of records.  Such a package is especially desirable considering the current limited ability of our lotus supplied e‑mail admin. tools or likelihood of a quick migration to other e‑mail products.

1.e   If using an archive/repository package, we can associate [multiple copies of] pointers to a store of the message, instead of including complete [and duplicate copies of] messages and attachments ‑‑ we will also have significant reduction in storage requirements.

Other points to be made in introduction:

1.f	

2. 	Technical (see also Annex E)

2.a	Standard software now in use for UNICEF CC:MAIL..
2.b	Future upgrades see also annex C:

3.	Storage: General discussion
3.a	On-line
i	server (enterprise)
-	users can share CC:MAIL archives?
-	can be centrally backed up
ii	User C drive - stand alone 
-	can not share CC:MAIL archives
-	limitation of disk space
-	not centrally backed up 

Note: on C DRIVE as Archives: the only way to preserve the drive "C" archives is for the users to be given more, LAN accessible and backed up space in a centralized store.  This is alternative to buying more big hard disks for the C drives.

3.b	Near-line:
For UNICEF headquarters The near line storage is an optical tape cartridge juke box which we will be installing before end year.  
i	Ramon to fill in
ii	

3.c	Off Line:
i 	Server
-	Backups [daily]?
-	Selected useful non current or historical material 
ii	User C drive.
-	Portable drives for a work unit 100 m.b.
[Mary Ellen to provide details approximately $200.00 for the drive and $160 for the 10 x 100 mb drives]

3.d	Retrieval from near-line and off-line
The procedure to get items back "on‑line" from the centralized store must be fairly straight forward and reliable without impacting negatively on the rest of system. If the user can not retrieve message easily, moving them will have the same practical impact as deleting messages.
 
3.e	For more details on future functions of interest see Annex B
B.1	Nested Folders, Nested BB
B.2	Compression to reduce storage:
B.3	Shared Repository for messages [only pointers transmitted]
B.4	Customized/Shared BB
B.5	Shared Folders:
B.6	Threading message - History of Conversation]

3.f	Rules/Decisions and selection Criteria for moving or deleting
See Annex C.6.	Rules for on-line,"near‑line" or "off‑line"?3.   There are some examples which reflect both paper records and the way E‑Mail is now organized. 

i.	There could/should be different rules for moving all messages to central store from the users: "IN‑Box", "Message Log",  "Drafts" and "Folders"-"Policy/Procedure/Precedents [PPP]" and "General".  This reflects practice for paper records in some substantive offices.

ii)	The idea of systematically eliminating all messages older than say 3 months may not be sound or necessary.  Trash and In box should have a short life, whilst folders a longer one.  The transmission log is a useful tool for which a longer life on a "near line" storage medium may be desirable 

iii)	We need different treatment of regular e‑mail messages (low storage) from attachment of GFSS and other data files (much larger storage).

3.g	Additional on‑line disk capacity and near line storage capacity is being installed as planned.

4.	USE/User

We have begun to analyze the composition of e‑mail to have a better idea of storage burden and growth patterns.

4.a	The are two main uses of electronic communication for:
-	Transmission:
-	Record keeping:
Chron Log:
Folders:

4.b	Some of the more innovative users, who are pressed for time and have limited resources at their disposal,  have assumed CC:MAIL to be the de facto standard for organizing their documents. They have become quite proficient using the search facility to locate items of interest.
This is a creative use of the medium and is the direction of the future.  However, due to present constraints on disk space it may be necessary to separate these user databases from those used strictly for mail exchange.  

4.c	Some consideration was given to allowing  stand‑alone CC:MAIL data bases on pc's for each user's individual use, if document management is the purpose. However these databases would not participate in any mail exchange. This could make the CC:MAIL perform a lot better for mail delivery.  However, backups of these stand alone databases would have to be assured.

4.d	If the backups and access could be assured e-mail messages could be a secure for the 90% of UNICEF records that are required to be kept for less than 10 years.

5.	Allowing time to adjust:

5.a	In order to protect potentially valuable E-mail records and to allow staff additional time to become familiar with the procedure for saving e-mail records to archives - we have backed up all the e-mail records to an off-site storage.  During December - February we will use one of the Near-line drives to allow users to view their old messages and send them to archives. It may be slow but effective and will allow needed time for work units to create/ update additional archives

5.b	In the future, whenever there is an upgrade or emergency need to reduce space on a server a similar procedure will be used.  In this way if staff are engaged in other projects, on leave or mission they will not have to fear returning to the office to find their messages deleted with no alternative.   

5.c	Reviewing older messages may be on a phased basis over a period of time [so as not to take up to much disk space].  I.e. for a limited time each Division or Work Group will be able to see their database as it existed as of a certain date before the mass delete.  It would necessarily contain all the deleted messages.  They would then have a certain time period [2 weeks] to send important messages to archives which match their current folders or archives. Possibly a near line or separate server will be assigned for this task. In effect nothing will have been lost and users are given the opportunity to update their archives for an extended period of time. 

5.d	Duplicate data backups of any days that exist prior to migration/upgrade or delete will be copied to other drives [even off‑site] to allow us some cushion while details are sorted out

6.	Total Cost to UNICEF:
Use as Transmittal and Record Keeping.
Only use for Transmittal:

Immediate Cost: Short term storage
Extended cost:

Cost of not doing:

Comparing cost of Disk space over time to keep additional records compared to cos if not.

Extra:
Storage space for paper/cabinets, 
extra staff costs for:
 filing and distribution,
re-typing needed information 
Loss of retrieval/access speed.
 
Set back to automation

6.a  To take advantage of the this tool to be more efficient, calls for more resources to secure our records and back up copies.

If not sure which is important and cant be sure info will be safe on-line or near-line until a decision can be made it will be printed out.  In effect some staff that are given the responsibility yet dont have clear criteria will print all or none.  In effect encouraging wastefulness or dishonesty/confusion. 

i	Actual cost for costs for disk space must be compared to benefit of having an effective, accessible backup store. The specific request for resources for disk space/access software has been made [or is being made] by IRM.

8.	Appraisal:  Financial Rules and "Appraisal GRID"
apply to all media of storage.

8.a	If it is the only copy - it is the record copy.

8.b	If we require staff to print out a record and/or backup copy then must make arrangements to increase printers and filing space.

8.c	Must make clear who is accountable to do it.

Annex A	User concerns with implementation

A.1	If do not protect E-mail, can not expect at some future date office support staff to produce from a deleted electronic record series. Resources are required to organize the material or at least to save the transmittal logs so a broad search can find the material.

A.2	Can not rely on judgement of operations staff to circumvent  guidelines to delete E-mail on a case by case basis as reason for poor planning for information storage and retrieval for reuse.

A.3	Should not discourage people who have planned for future and begun to invest time identifying E-MAIL folders and relating items, thereby "adding [associated] value".

A.4	Appraisal and destruction/retention can be more pinpointed by folder distinctions

A.5	With all records [paper or electronic], most time you need only use a small amount of the documents items you save.  However it is difficult [impossible] to exactly predict which ones you will need.  Therefore, all form a certain series must be kept -- at least for a reasonable amount of time  [4 to seven years for most financial records].

A.4	All in a related "group" need to be protected for the "total retention time" of the most important records of the group.  This is reason for creating sub-series {groups) with separate retention times.

A.5	Planning for paper:  If it is decided not to use any electronic copies as "record copy" but will be requiring paper copies. Then planning requires adequate filing staff, filing cabinets and urging use of "computers as transmittal but not storage and retrieval. This seems counter to the direction we wish to go.

==============================================================
Annex B	Future functions of CC:MAIL

B.1	Nested Folders, Nested BB
B.2	Compression to reduce storage:
B.3	Shared Repository for messages [only pointers transmitted]
B.4	Customized/Shared BB
B.5	Shared Folders:
B.6	Threading message - History of Conversation
B.7	Lotus CC:MAIL and Lotus Notes Mail

B.1	Nested Folders, Nested BB

Future issues of E-mail [CC:MAIL] will have nested folders and possibility nested BB. This will assist organizing electronic records.  The user will be able to see the level of detail required by clicking on the outline of BB or Folders.

B.2	Compression to reduce storage:
i.	At present when some one stores their message to the personal archive on the C drive there [is/is not] some compression of the data.
ii.	If we were to store to a common drive on a designated server, it may be possible to compress some of the data for backups.

B.3	Shared Repository for messages:
At present each time a message is passed between users an additional copy of the message is stored.  

i.	Lotus has been requested to introduce the ability within a specific location to store the basic message to a single repository. 

ii.	The pointer to the repository store would only need to be copied and transmitted. 

iii.	

B.4	Customized/Shared BB

In the short term, [possibly in the next version of CC:MAIL] it will be possible to customize bulletin boards for small groups.

Any message sent to all the users in the group would be stored on the common bulletin board for future reference. Users would be encouraged to delete the message after receiving unless they would be adding to the message 		

B.5	Shared folders:

It may be possible to set up shared archives on a LAN where users can send shared messages.

B.6	Threading message - History of Conversation

Some E-mail packages now have the ability to keep the history of conversation and automatically link previous messages on a similar subject.  Only the pointer to the previous messages need to be sent with the message. This facility could cut down transmittal and storage costs

B.7	Lotus CC:MAIL and Lotus Notes Mail

Lotus Company says? most of desired upgrades to CC:MAIL will be obtained by switching to Lotus Notes mail.  System administration could be much higher. 

Annex C 	Recent Questions related to E-MAIL

Common QUESTIONS: E‑Mail, Record Copy, Access etc:[Draft for discussion]

Table of Contents:

1.	Electronic copy of "CC:MAIL" be considered a record copy.
2.   Migration to future e-mail and legacy data.
3.	Disk space, alternatives to print records, budget?
4.   Electronic subject files; printed copies or neither?
5.   Delete or "move messages
6.	Rules for on-line,"near‑line" or "off‑line"?
6.a)  "IN‑Box"?
6.b)  "Message Log"
6.c)  "Drafts"
6.d)  "Folders" [Policy & procedure] & [General]
6.e)  "Bulletin Boards"
7.   How long records kept off‑line or near line.
8.  	Impetus for moving messages and user C drive Backup?

ANNEX C Details Annex C 	Recent Questions related to E-MAIL

QUESTIONS: E‑Mail, Record Copy, Access etc:[Draft for discussion]

1. Can electronic copy of "cc:mail" be considered a record copy.

ANS: In many cases, it is IN FACT the record copy, because it is:

1.a)   the only copy, it therefore becomes the 

2.b)   "best copy available" and therefore

3.c)   the  record copy.

2.   What if organization moves to another e‑mail package in a few years ... or new versions in 10 years etc ?.

ANS: Part of the functional requirements of all new versions of e‑mail:

2.a)   It can read legacy data for direct predecessor; or at minimum.

2.b)   include the software that does convert legacy data.

3.   Does the problem of Disk space mean there are no current alternatives to print out messages of record even if only be a very small proportion?  What about the budget?

ANS: Previously disk space was seen as a potential obstacle. However, IRM technical staff and consultants brought during part of the management reform exercise have stated that:

3.a)   disk space is not now the issue holding back having a effective, accessible backup store;

3.b)   even functional "near line" storage is a few months away;

3.c)   In 1990 the choice appeared to be between 
expending huge sums of money for electronic retention of MAIL and compromising on what is organizationally affordable. It seemed that hardware budgets would need to be increased significantly.

3.d)   Necessary budget for equipment & disk space and 
related software is adequate for at least a year [6- 8 mo.?]. Future needs implications are being examined. See detail on current status and IRM plan for next 12 months in ______

4.   How many people actually:  file away their electronic mail electronically in subject files?; file printed copies? or don't file at all?

ANS: Even if only a small number or select key people have begun to be more concerned with electronic filing we must approach the problem in a coordinated manner.
4.a)   As we try to capture more information on‑line 
[via scanning, text capture] at the earliest time in the life cycle of the record, it is counter productive to be telling people to be printing out paper copies where a signature, specific masthead, handwritten notes or image is not required.

4.b)   even if many are not adding value to the records 
by linking to their subject files, their electronic message log has in effect automated their log for outgoing messages.

4.c)   to cover the organization for legal reasons 
until the issue is fully resolved and the systems for backup, recovery etc are thoroughly audited,  it may be necessary to advise people to print out important documents. 

But we need to make clear which documents these are and 
state that future systems will do away with this practice except in exceptional cases for historical documents and where actual signatures or original forms are required for authenticity checks. 

4.d)   it could be tempting to only advise staff to 
review their e‑mail transmission logs etc and print out messages of record value.  But it seems even before the upgrades to CC:Mail [and  Notes Mail] we have to acknowledge that  e‑mail has record keeping value. To say e‑mail in electronic form is a personal information file only, will not be helpful in 1996‑1997.

5.   What is the difference between "deleting" and "moving the messages?

ANS:  It is possible to move  messages "near-line" or "off line" to a centralized/secure store and not delete them.

5.a)      This allows the system to process more 
current records quicker while still having older records accessible as required. 

5.b)      To be effective and practical, there has to 
be set up simple procedures to get items back "on‑line" from the centralized store. If it is not fairly straight forward and reliable without impacting negatively on the rest of system it is the same as deleting messages.

5.c)      Save centrally should include connections to 
user defined folders etc.  This should encourage those who are adding value to records by preserving the pointers to related items.  This will also assist in applying rules at later stages.

RULES/DECISIONS: 

6.   How would the system know when to move records "near‑line" or "off‑line"?  What rules will be used to make the decision?

ANS: In this respect e‑mail records are similar to paper.  There could be different rules for moving all messages to central store from the users directories.  The time frames would be agreed for moving records in users: 

6.a)  "IN‑Box"?

6.b)  "Message Log"
6.c)  "Drafts"
6.d)  "Folders" Eventually some work units/individuals 
may have two types of subject folders with similar titles but distinction between:  "Policy/Procedure/Precedents [PPP]" and "General".  This reflects current practice in some substantive offices. 
6.e)  "Bulletin Boards"

7.   How long do records need to be kept once they are off‑line or near line. Will everything just be kept permanently?

ANS: if the electronic records such as E-mail system 
even in part have become the defacto record keeping system of the organization:

7.a)   The destruction retention schedules which apply 
to paper records must be also be applied to electronic records which serve the same functions.

7.b)   For Financial records the circular [CF/DFAM/FC/025/rev1] applies

7.c)   The general appraisal grid will be consulted for destruction/retention decision for specific types of electronic records [CF/IC/1986‑112 and CF/NYH/IRM/193‑174/176]

8.  What was the impetus for the recent discussion on deleting or moving e‑mail messages from users directories?  Should users get bigger C drives to use as ARCHIVES and back these up?

Ans: It came up during the preparation for the migration to DB8 (release 6) database for cc:Mail,

8.a)     Even if we establish the "C" drives as user 
Archives there has to be some automatic way to back up these drives and protect against local failures. The only practical way to preserve the drive "C" or other archives is to allocate, LAN accessible and backed up space in a centralized store.  This is alternative to buying more big hard disks for the C drives and backups. 

8.b)     IRM was planning to migrating the databases 
for various post offices in a staggered fashion (with a tentative schedule below) in the coming weekends, with the corresponding user workstations upgraded prior to the database migration.

8.c)     Since the database sizes was growing 
continuously, it was thought to take this opportunity to the clean up the databases before being migrated.  The migration is time‑consuming and needs disk space about 3 times the original Database for each PO (which will be released after migration).

8.d)      After discussions with some IRM staff it 
initially seemed reasonable to keep one year's worth of messages and possibly delete all the messages older than 1 July 95 (i.e. messages for last 6 months of 95 and the whole of 96 will be kept).

8.e)     Further discussion among a wider group of 
staff including the RAM officer led to a fuller understanding of the issues and implications of the proposed action. 

Annex D:	Backup schedule and Disaster Recovery plan

D.1:	Back up schedule:
D.2:	Disaster Recovery Plan
D.3:	University sample policy
D.4:	Related issues Information Access & Security [e.g interagency Policy]
---------------------------------------------------------
D.1	Back up Schedule:on-line,"near‑line" or "off‑line

D.1.a Present Policy for WANG and HP on-line back up:

Periodic:

-	DAILY: Back ups each night [Mon-Thur] of incremental changes [edits/add & update]

-	WEEKLY: Full back up each Saturday night.

-	Quarterly and Annual Backups [Periodic]
- 	How long kept [to be confirmed]
-	Conditions [to be confirmed]
-	How often data checked/copied/migrated  

- 	Off Site [dual site] services employed.

-	Number of backups [generations retained] 16
-	1 Gen is in UNICEF House
-	15 Gen  with vendor [Eman or mark to give details]

-	Previous Documents [Ramon suggests Eman, Mark, Michael might have previous docs]

-	Costs associated with options [to be discussed - added]

D.1.b	Present Policy for NYH LAN on-line backups
Michael, Mark  Riza or MaryEllen to provide details]
different type of Server:
Mission Critical?
Application Specific
Novel NetWare Server: WP/client
 enterprise, 16, 25, 26

Different Policy may depend on type of server and data stored on it.

-Working = 5 Main Stream. 
Rad level 5: Immediate Replace if one goes down, data recovered from other four. Self-healing

-	DAILY: Back ups each night [Mon-Thur] of incremental changes [edits/add & update]???

-	WEEKLY: Full back up each Saturday night???.

-	Quarterly and Annual Backups???
- 	How long kept [to be confirmed]
-	Conditions [to be confirmed]
-	How often data checked/copied/migrated  

- 	Off Site [dual site] services employed.

-	Number of backups [generations retained] ??
-	? Gen is in UNICEF House
-	?? Gen  with vendor [Mike, MaryEllen or Riza to give details]

-	Previous Documents [.............might have previous docs]

-	Costs associated with options [to be discussed - added]

D.2	Disaster Recovery Policy

D.2.a	General issues:

D.2.b	Previous comments/documents examples 
- Auditors comments
- Sample Region/Country office Plan

D.2.c	Future Plans
See IRM draft from Steve Fazio and Mark Prutsalis on disaster recovery planning and guidelines.  To be IRM standard operating procedures manual for field offices and regional offices.  Based on discussions in IRM, the work of WCARO and Audit Division on disaster planning. Specific guidance for backup and restore procedures, anti‑virus protection and security, are still being revised. Draft shared with regional IRM officers, IRM staff in Geneva and Copenhagen, and the Division of Internal Audit ‑‑ in preparation for the IRM analysts meeting in New York the first week of December. Comments welcome table of contents follows
-----------------------------------------------------------
D.2.c.i	IRM DRAFT: Table of Contents

 9	Disaster Planning and Recovery Guidelines
9.1	Background
9.1.1	Overview
9.1.2	Objectives
9.1.3	Causes of Disaster to IRM systems		Natural Disasters:	Unnatural Disasters:
9.2	IRM Roles and Responsibilities/Standard Operating Procedures -- Disaster Recovery Planning
9.2.1	Components of a Disaster Recovery Plan:	Standardization:	Backup and Restore Procedures:	Power Protection and Continuation Measures:	Anti-Virus Measures: Security:	Equipment	Telecommunications Preparedness:
9.2.2	Steps in creating a Disaster Recovery Plan
9.2.3	Coordination
9.2.4	Planning for evacuation
9.2.5	Implementing a Disaster Recovery Plan
9.2.6	Local IRM Disaster Recovery Planning and Implementation Checklist

D.2.d	Specific Points for further consideration:

D.3	[SAMPLE for UNIV Policy found by RAMON on WWW
http://voxel.musc.edu/mmi/data.htm

>                              Data Storage > 
> Data Storage Policy:
> 
> Currently, the hard drive resources of the Core are stretched to the > limit. Capacity has reached critical levels and often impedes work
> until files can be moved. Beginning October 1, 1996, the following > policy will be adopted:
> 
> ALL users are responsible for the archiving of their data onto their > own resources. A wide variety of options are available to users for > data storage (see below). ANY DATA FILE, IMAGE, or PROGRAM not OWNED > by the Core will be DELETED. Our practice will be to purge our hard > drive resources of those files EVERY FRIDAY.
> 
> Please allow enough time in your scheduled resource use for moving > your data files off of the hard drives. Core staff will move your
> files for you at a cost of $30 per hour (this applies to ALL USERS). > 
> Data Archiving Options:
> 
> 1. The campus network can be used to transfer files to the user s data > storage devices. Several users have successfully moved data files over > the network to optical drives or similar devices attached to their lab > or office computers. Core staff can train you in implementing this
> option from all Core Computers.
> 
> 2. Removable storage media can be purchased from the Core (see above). > Current options are:
> 
>    * Panasonic optical disk (capacity 1 Gb; unreliable; read/write) > 
>    * Syquest disk (capacity 270 Mb; somewhat unreliable; read/write) > 
>    * Digital Tape (capacity 4 Gb; very slow) > 
>    * CD ROM (capacity 650 Mb; very reliable; read only) > 
> Data stored on optical and Syquest disks can be modified (read/write) > and is transferred quickly; but both types are expensive (~$0.15/Mb) > and unsafe for long‑term storage (entire disks have become corrupted > resulting in total loss of data). If you have ANY difficulty reading

> data from these disks, immediately cease using it and bring it to Core > staff. We might be able to rescue your data.
> 
> Digital tape, although cheap (<$0.01/Mb), is VERY slow and requires > Core staff assistance. The tape option is more appropriate for data
> generated on the INDIGO workstation. Please allow 24 hours (overnight) > to backup or restore data with this option.
> 
> CDROM is cheap (<$0.02/Mb), reliable and fast, but the data, once
> written, cannot be changed (read only). We now have the capability to > write multiple sessions (datasets) to a CD rather than having to fill > a disc in a single burning. CDs can be prepared in a wide variety of > formats:
> 
>   1. HFS (Mac format) files and folders retain all Mac characteristics >      (e.g. icons) but cannot be read on non‑Macintosh computers.
> 
>   2. ISO 9660 is a format standard to all types of computers using
>      CDROM drives (DOS, Windows, UNIX, Mac, etc.). Long filenames and >      custom icons are NOT supported.
> 
>   3. Mac/ISO Hybrid combines the benefits of ISO 9660 and HFS on a >      single disc, but only ONE session is allowed per disc.
> 
> If your data does not use long filenames or custom icons (e.g. BIORAD > files) you should consider using ISO 9660 format. If you want to
> retain the Mac‑like appearance of your files and folders, and don t > worry about ever reading the CD on a UNIX or DOS machine, you should > use HFS format. If your data is a combination of these choices, the > Mac/ISO Hybrid format is best, but you will need to accumulate about > 600 Mb of data to best utilize the space available on a CDROM.
> 
> Core staff strongly suggests users consider eventually moving all data > to CD. We now advise users to employ a small set of optical or Syquest > disks to accumulate enough data to fill a CD. When the disks are full > (or the data is ready for long‑term archiving) the files can be
> quickly moved to CD. The optical or Syquest disks can then be > re‑formatted and made available for fresh data.
> 
> Syquest Disk Users: If you use Syquest Disks you may keep them in the > Core Syquest Library Area. We use a disk‑catalog program on these
> volumes which maintains an easily‑searched database of the files in
> the entire library. If you keep your disks in this library please keep > Core Staff informed (E-mail, memo, etc.) of changes made to the disks
> so that we can update the database. Users can also be trained to run > the catalog program for the purpose of searching for files and/or
> updating any changes to the file structure you have made. 

D.4	Information Access and Security

e.g interagency policy

Annex E:	Reference to further technical information

-	University Policies on E-mail available on WWW
-	NARA Regulations
-	US Supreme Court Rulings
-	Inter Agency Task Force
-	User-Group Comments on CC:MAIL latest versions
- 	Best Practices & lessons learned

----------------------------------------------------------
SAMPLE from: http://www.unc.edu/~gogan/policy.html

>     Policy Issues Arising from a Networked Information Environment > 
>                         from CAUSE Discussion Session: December, 1995 >                           Clair Goldsmith, University of Texas‑Austin >               Anne Parker, University of North Carolina at Chapel Hill > 
> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ >      Many issues are emerging related to the proliferation of networks > and connectivity to the Internet: free speech, censorship, e‑mail
> privacy, ethical standards, copyright and intellectual property in a > networked information environment, defining and managing
> "institutional information" on the World Wide Web, and for academic
> institutions, issues of academic freedom and student records privacy. > Some states are considering legislative action that would prevent the > use of the Internet by minors, and Congressional concerns with
> pornography may well create difficult management situations for many > sites. Many institutions are moving toward establishing policies to > deal with these issues.
Follows with list of about 10 Universities and current policies.
==============================================================
http://www.ucop.edu/ucophome/policies/E-mail/email.html >                   Electronic Mail Policy
  University of California   Office of the President >                             August 1, 1996
 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ 
> TABLE OF CONTENTS
> I. INTRODUCTION
>      Cautions
> II. PURPOSE
> III. DEFINITIONS
> IV. SCOPE
> V. GENERAL PROVISIONS
>      A. Purpose
>      B. University Property
>      C. Service Restrictions
>      D. Consent and Compliance
>      E. Restrictions on Access Without Consent >      F. Recourse
>      G. Misuse
> VI. SPECIFIC PROVISIONS
>      A. Allowable Use
>           1. Purpose
>           2. Users
>           3. Non‑Competition
>           4. Restrictions
>           5. Representation
>           6. False Identity
>           7. Interference
>           8. Personal Use
>      B .Security and Confidentiality >      
  C. Archiving and Retention
> VII. POLICY VIOLATIONS
> VIII. RESPONSIBILITY FOR POLICY
> IX. CAMPUS RESPONSIBILITIES & DISCRETION > APPENDIX A, DEFINITIONS
> APPENDIX B, REFERENCES
> 

ANNEX F: Appraisal Grid for Destruction and Retention

[CF/IC/1986‑112 and CF/NYH/IRM/193‑174/176]

SEE DOCUMENT CF/NYH/IRM/RAM/1996-298 for revision of Annex G

ANNEX G:	Appraisal Grid and E-mail Categories or Samples:

G.1	The rules to secure records will be reflective of destruction retention schedules [e.g. Financial Circular 25 and general appraisal grid for specific types of records].

G.1.a	The type of records to be sent to Electronic stores may be similar to those stored in manual file areas:

Electronic Store    -	Manual Storage Area 
  
 	On-line   		= 	Desk-At Hand
Near-line 		= 	Common Work of File area 
Off-line			=	Record Storage Center or Archive

G.1.b	Need to move by combination of Date, Size and what is likelihood of record copy being included

G.3	Apply Rules for on-line,"near‑line" or "off‑line"?

i)  "IN‑Box"?:-	 	60 day max?

ii) "Message Log" -	1 year Minion-line & 2-3 year near line and then off line

iii)  "Drafts"		-	1 year on line then near-line

iv)  "Folders" [shared?]
-	[Policy & procedure] -	5 year min on-line, then near-line
-	[General] -			2 year min on-line, 3 year min off line then decide on further retention of destruction
-	Specific subjects	-	Follow Financial Circular and what has been agreed for series 

v)  "Bulletin Boards" [nested]
Temp announcements 	- 	2 month max
Background information -	2 year and then review for near-line

See also CF/IRM/RAM/1996-298 appraisal Grid adapted to E-mail.:

Annex H:  Discussions/consultation on move/delete of users files:

1.  Actions or decisions on move or delete of user files from a central system or store should be accompanied by sufficient time for discussion/consultation with users.

2.   At one time users and  long term guardians of UNICEF records were not consulted regarding decisions on accessibility and destruction for paper records.  Therefore, the responsibility had to be confirmed to be outside of the strictly "administrative" control. Some of the same issues and standards apply for other messages irrespective of the media of creation or storage. CF/EXD/1983‑2867

3.   Saving space and efficiency of operations is important [and the pressure for quick fixes is considerable], but so is planning, advance notification and true consultation so that "win/win" solutions can be attempted.  We must acknowledge and honour conflicting pressures.

Annex J:	Related papers of Interest:
j.1.	CF/IRM/1996-??? Information Management Discussion Note [Draft 30 Oct 96]
j.2.	CF/EXD/1996-015 Use of Electronic Mail 03 Oct 1996
j.3	UN/ST/AI/386 Electronic Mail Policies and Standards 23 Aug 1993 [RAM/1996-299] 
j.4	CF/IRM/IP/1996‑066 "Electronic Discussion Databases/Document Conferencing"
j.5	CF/IRM/IP/1996‑067 "Selection of a Document Repository Software Tool"
j.6	CF/IRM/IP/1996‑068 "Submission of Documents for the UNICEF Central Electric Document Repository"
j.7	UN/ACC/1996/ISCC/6 Interim Report of the Task force on Document Management Technology [02 Sep 1996]{RAM/1996-295}
j.8	UN/ACC/1996/ISCC/6/Anx001 Report of the Consultant for the Task force on Document Management Technology [02 Sep 1996]{RAM/1996-294}
J.9	CF/IRM/RAM/1996-320 Users Guide for Off Site Backup Storage Service for Electronic Media  used by UN offices for emergency purposes. Memo from Information Security Unit, Elec Services Div, OCSS, DAM [15 July 1996]

Annex K:	Cost of Disk Space Comparisons
k.1	1-2 Year Previous, Now, 1-2 year Projection
k.2	Disk space vs Volumes/types of Messages
k.3	Disk Space Compared to other costs [Consultants & hidden]

k.1	1-2 Year Previous, Now, 1-2 year Projection

On-line:

1-2 year previous 	= 	2,000 per gigabyte

* Now (Oct 96)		=	700 per gigabyte       

1-2 year Projection =	300 per gigabyte

* Note on Now
*	Should be purchased in sets of 7 units
* Current cost for 7 units = $13,750
-	RAW capacity each unit@4G
-	Total Raw Capacity for 7 Units = 28 G
-	Accessible capacity = 5 of each seven units.
- 	one unit per 7 = Hot spare
-	one unit per 7 = parity
-	Total Available Capacity per 7 Units = 20 G
-	Cost controller board per 7 units = $2,100
-	Cost rack per 7 units =	$2,550
-	Cost labor install per 7 units =

K.2	Disk space vs Volumes/types of Messages

-	types of messages impact on how much volume is required.

-	Big attachments.

-	Need Reasonable Checks to assure least cost transmission. 

-	Least cost must consider degradation of rest of system to send. [E.g. soon video clips might be sent world wide but rest of system would be reduced to crawl while video clip was transmitted unless it is greatly compressed.] 

-	Which messages better sent on disk via Fed express.

- 	Band Width issues

K.3	Disk Space Compared to other costs [Consultants]

Consultants are between $ 60-90,000 per annum
Temp GS Staff are Between $30-45,000 per annum

K.3.a	Consider the hidden cost of not having the information available on-line, near-line or [delayed accessible] off-line.

K.3.b	Users are best able to give examples of hidden costs of not having information.

K.3.b	i)	Begin Printing out paper again [just to be sure].
ii)	Time spent searching because not sure if sent or not.
iii)	Request more temporary/secretary/clerk assistance to file and retrieval
iv)	Other things not being done by middle managers because they can no longer count on the quick information retrieval.

K.3.c	Cost of having each, Division, Sect, Unit chief log for last 2-5 years  - compared to not having.

K.3.d	Cost of having e-mail messages [especially those in folders] as reliable/ protected/ accessible as paper records files for all staff as compared to not having. [in office, in common area, off-site records center or archives] [See also Annex F and G for relation to parallel retention destruction schedules]

Annex L:	Short List Archive Guideline
l.1	3 main points to be addressed
------------------------ detail -------------------------

Annex L Short List Archive Guideline:

1.   ARCHIVING ‑ BACKUP & RULES at Work Station:
2.   APPRAISAL ‑  Policy, Procedure & Precedent files
3.   WORK PLAN ‑ Schedule time/responsibility for backups
4.   BUDGET  ‑ for Personal Drives and LAN Backup
5.   TRANSFER  ‑ Disks or Back up drives off site

------------------- details follow  ------------------
1.   ARCHIVING, BACKUP & RULES at Work Station:

1.a  Archive outgoing LOG and Folders to C drive at least once a quarter.

1.b       Once every four months back up The C drive to 1 gigabyte disk using the portable external drive. 

1.b       If due to limited space on C drive, it becomes necessary to remove older archives, first make copies on two separate one gigabyte disks. Keep one copy in a secure place registered with the divisional focal point.  The other should be kept in the work unit.  Label each with work unit name, date and key information contained.

1.c.      Rules can be set to transfer messages automatically to Archive from the Chron log of specific files that are beyond a certain date [4 months].

2.   APPRAISAL: Policy, Procedure & Precedent files

2.a.      Make distinction between Policy/Procedure/Precedent file and other types of folders [transaction and temporary].  Plan extra backups of the Policy Procedure files.  These files from substantive activities are the only files that automatically must be kept for more than 10 years total retention time.

2.b.      All rules that apply to paper also apply to same information contained in electronic files. Consult the appraisal grid available from the RAM unit RAM/1994‑174/176. [For policy refer also to executive Directive CF/EXD/1983‑2867]. For paper files of substantive activities which have not been completely printed out and kept in an accessible manner, the responsibility to protect the electronic files also exists.    

3.   WORK PLAN ‑ Time Management

3.a.      Every quarter, schedule the focal point to assist each head of section and work unit to make the appropriate backups of the C drive, until the staff in the unit can take over.  

3.b       Consider the time invested in making backups ‑ compared to overall cost of not doing. For example consider the benefit of searching electronically compared to finding paper and having to retype if necessary.

4.   BUDGET for LAN & Individual Drive Backup

4.a       Divisions are encouraged to buy one drive and back up disks for each focal point [Estimated cost $200 per drive and $20 per disk]. 

4.b       Indicate to IRM if your work unit requires additional on‑line or near‑line central storage so that the required backups could be scheduled and performed on a regular basis without interrupting the work of the unit [indicate if there are funds available for special backups].  Alternatively indicate if a separate server and backups could be administrated within the division/office. 
If so budget for server and near‑line storage etc.

5.   TRANSFER DISKS or Back up drives off site

5.a       If information files and logs are only being archived to individual C drives, at least every two years send the properly labeled archive disks [1 gig] to RAM unit or other identified IRM work unit for filing [either the focal point copy or work unit copy]

5.b       If division is maintaining its own backups for the LAN inform IRM of procedure used and logs kept.  Be especially vigilant about storing copies of annual/quarterly and "archive ‑ complete move of date" off site. 

Annex M   3 main points that must be addressed:

1.   Attachments
2.   Transmission vs. Record keeping, 
3.   Disk space/back up cost and comparisons:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Details follow ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1.   Oversize attachments:  

1.a       We must be able to identify and automatically transfer/delete large attachments while retaining messages;

1.a       Users must begin to identify in the message the source of attachment and from where it can be obtained if the copy gets separated from the message  

2.   Transmission vs filing use:

2.a  While recognizing the mission critical nature of the transmittal function of e‑mail, we need to encourage/allow staff to assist their other office work or record keeping responsibilities without degrading the transmission capabilities. [for both of these issues automatic near‑line transfer of folder contents should give us the required capacity/flexibility.]

3.   Disk, Back up, Costs & Comparisons:

3.a  We must provide a secure/simple way to file electronically that is as accessible etc. as paper [and budget for required disk space and backups]. 

3.b  We need to point out the hidden costs [paper, filing etc.] of relying on solely on paper filing for all information which may be required/reused.

3.c  We need to provide real costs for disk space etc. to make helpful budget comparisons

3.d  Conversations must focus not only on cost of electronic filing but also cost of not filing.  e.g. Disk space might cost $100 per user to have electronic chron log available for five years vs. cost of retyping even 5 items per user is $300. 	

Annex N:	Draft DB Tables for Tracking Backups.
N.1 	AM_BAK01.DB =	System type Identification General, hardware box, application types, etc.
N.2	AM_BAK02.db =	Backup specific types, frequency, generations, exceptions 
N.2	AM_BAK03.db =	Frequency Type, description
+  
Back up container