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.
Library of Congress