NAME: Changes to field 355 (Security Classification Control) for downgrading and declassification data
SOURCE: CENDI (Commerce, Energy, NASA, Defense, and Interior Departments Cataloging Committee)
SUMMARY: This proposal suggests defining subfield $g (Downgrading date), $h (Declassification date), subfield $j (Authorization) and redefining subfield $d to limit it to downgrading or declassification events.
KEYWORDS: Authorization; Declassification; Downgrading; Field 355 (Security Classification Control) (Bibliographic); Security Classification Control; Subfield $d (355 Bibliographic); Subfield $g (355 Bibliographic); Subfield $h (355 Bibliographic); Subfield $j (355 Bibliographic)
RELATED: DP55 (Nov. 1991); 92-20 (May 1992); 94-17 (May 1995)
STATUS/COMMENTS:
5/1/97 - Forwarded to USMARC Advisory Group for discussion at the June 1997 MARBI meetings.
6/28/97 - Results of USMARC Advisory Group discussion - Approved as amended. Subsequent to the meeting, a representative from DTIC requested that 355$j (Authorization) needs to be repeatable.
8-21/97 - Result of final LC review - Agreed with the MARBI decision.
PROPOSAL NO. 97-13: Changes to field 355 (Security Classification Control) 1. BACKGROUND For several years CENDI, a group of government agencies including the Departments of Commerce, Energy, Defense, Interior, NASA, and related agencies, have been working on a mapping between the database structure that they currently use to share information and the USMARC Format for Bibliographic Data. In most cases the data elements currently defined in the USMARC format are sufficient. This proposal covers elements used to record information related to changes in security classification, in particulary, downgrading and declassification data and the authorization for such changes. 2. DISCUSSION Some agencies within the CENDI group handle a significant number of documents to which a level of security classification has been assigned. Field 355 (Security Classification Control) was defined in 1992 based on proposal 92-20 (Addition of two fields to the Bibliographic format to accommodate security needs) to satisfy the needs of the U.S. intelligence community. The original structure and content of field 355 was based on input from intelligence agencies that set much of the security policy applied in the U.S. and abroad. CENDI agencies often apply classification policy established by other agencies, using classification systems maintained by other agencies but bearing the responsibility for classification and declassification themselves. As currently defined, field 355 does not accommodate information relating to changes in security classification in a sophisticated way. Subfield $d (Downgrading or declassification data) was designed to handle this kind of information but does not provide adequate content designation to differentiate between downgrading dates and declassification dates and other events that affect classifications status. There is also no separate subfield where the authorization for a change in security classification (for example, executive orders requiring downgrading after particular events) can be recorded. At present, dates and events related to security classification would be mixed in subfield $d. It is not clear where the authority for security classification could be recorded. It may be only implicitly named by the classification system used (e.g., if the NATO system of security classification has been used, NATO is also assumed to be the agency that assigned the security classification). CENDI agencies would like to be able to differentiate between downgrading and declassification dates. Regular processing of bibliographic data in their internal data bases is performed to identify items scheduled for downgrading or declassification. They would also like to be able to identify the authorization for changes in security classification. Since it originally worked with MARBi to define field 355, the Defense Intelligence Agency (DIA) has also found that the data elements in field 355 are not adequate with regard to changes in security classification. With the development of the Internet, and their own intelligence network IntelLink, the need to control changes to security classification has become more acute. The addition of several new data elements should accommodate current needs. Existing field 355: 355 Security Classification Control (R) Indicators First Controlled element Second Undefined Subfield Codes $a Security classification $b Handling instructions $c External dissemination information $d Downgrading or declassification data $e Classification system $f Country of origin code $6 Linkage It is generally agreed that separate subfields are needed for dates relating to downgrading and declassification. Within the intelligence community, downgrading and declassification are considered quite different. Downgrading involves changes to security classification, from a higher level to lower lever of classification. Declassification involves the removal of any security classification on a item, although it is normally necessary to record when the declassification occurred and what the authorization was. The definition of two new subfields for downgrading and declassification dates would satisfy this need. The dates recorded in these subfields would be structured; either future or past dates would be possible. Subfield $g (Downgrading date) and subfield $h (Declassification date) have been suggested. The dates need to be represented in a standard way that deals with the approaching century change. ANSI X3.30 (Representation for Calendar Date and Ordinal Date for Information Interchange), which specifies that the date be recorded using eight numeric characters in the pattern yyyymmdd (4 for the year, 2 for the month, and 2 for the day), is the standard used for other USMARC data elements and is the logical choice here. Examples: 355 0#$aSecret$bNOFORN$g20230301 [Security classification for a document that is eligible for declassification in March 2023] In some cases declassification is the result of an event, not a specific date. An event might be the execution of a plan (for example, a battle plan), which prior to execution it would be quite secret, but after its execution would be openly known and discussed justifying no continued secret security classification. If subfield $d were limited to non-date information (and renamed "Downgrading or declassification event), it could continue to be valid. 355 0#$aTop secret$bWNINTEL$ddeclassify after execution of plan [Security classification, handling instructions, and declassification event for a document] Automatic downgrading or declassification is often set by executive order or some other authorization. A new subfield is needed for this information. It is not clear that it is covered by any of the existing subfields in field 355. Authorization information would not likely be structured. It many cases it may consists of note-like text. Although field 355 is inportant to CENDI, DIA, and other agencies, it is not widely used in the MARC community where security classification is not generally assigned to library materials. The impact of changes to field 355 should be relatively minor in existing USMARC systems. There should be little or no impact on the majority of existing USMARC records in which field 355 is very unlikely to occur. 3. PROPOSED CHANGES The following is presented for consideration: - In the USMARC Bibliographic Format, rename subfield $d in field 355 "Downgrading or declassification event" and limit it to events (i.e., no dates). - In the USMARC Bibliographic Format, define a new subfield $g (Downgrading date) in field 355. This subfield would not be repeatable. - In the USMARC Bibliographic Format, define a new subfield $h (Declassification date) in field 355. This subfield would not be repeatable. - In the USMARC Bibliographic Format, define a new subfield $j (Authorization) for recording information that identifies by whose authority a change in security classification was made. This subfield could contain the USMARC code for an agency or textual information. Subfield $j would not be repeatable.