security purposes - tracking is done w/ barcodes entered into the preservation metadata database, and vault system databases do not usually "refresh" with each other, so the 2 are not in sync.
Again, not saying by any stretch this should/ could be considered "best practices" - it's just what typically happens. Refresh cycles (while another topic) are also a problem in this environment, as there is typically less interest in subsequent updates of the data tapes that have not "recouped" their initial cost of creation. I guess I'm trying to convey there is more interest in keeping the 10-20% of backups that have been profitable than a consistent policy that treats all digital preservation files equally.
The hope is that one would not have access to the LTO tape...again, not by any stretch would I consider this the best approach, but there is a level of physical security for unauthorized people to access the tape.
John
On Feb 13, 2012, at 12:34 PM, Karen Cariani wrote:
> This may be a naïve comment/question, but are you talking about content
> encryption for security purposes or tracking purposes?
>
> On 2/13/12 12:46 PM, "John Spencer" <[log in to unmask]> wrote:
>
>> Andrea,
>>
>> I'll have a go at it - not going to get too far "in the weeds", but maybe
>> this will be of some help. Please see my inserts below in your message.
>>
>> John
>>
>> John Spencer
>> [log in to unmask]
>> www.bmschace.com
>> office 615.385.1251/ fax 615.385.0153
>> mobile 615.714.1199
>>
>> On Feb 13, 2012, at 11:17 AM, Goethals, Andrea wrote:
>>
>>> I hope you all don't mind my starting this series off. I think this
>>> would work best if we pass the virtual baton around to a different
>>> person after each topic. We can queue up a list of topics on the wiki so
>>> people know what's coming next.
>>>
>>> The first topic is encryption in preservation storage. I am thinking
>>> about hardware or software or file encryption primarily imposed by the
>>> repository (but whether or not you accept content encrypted by others is
>>> also interesting). I am thinking less about encrypting for transport
>>> (e.g. https). Say what you want about it but I'll pose some questions to
>>> get you thinking about it.
>>>
>>>
>>>
>>> * Do you have any opinions on it? What are your reasons for
>>> your opinions (gut feelings are OK)?
>> The majority of the preservation data we deliver to our clients is stored
>> on LTO data tapes - without encryption. We do use WORM capability if the
>> client is OK with it. Our reasons are mainly based on the the assumption
>> that we do not have any control over who can access the tape, now or in
>> the future, and staffing changes might stifle the client's ability to
>> recover the preservation files ("now where did the last person put the
>> list of encryption keys?")
>>>
>>> * What kinds of problems do you think it might create in the
>>> future?
>> See above. We're most concerned that staffing issues combined with
>> object-based vault management infrastructures in place could lead to
>> problems. Certainly not saying that is the best rationale, but it is
>> based on current reality.
>>>
>>> * Do you have any current requirements to do this (laws,
>>> policies)? What are the conditions under which you need to encrypt? Do
>>> you know of any upcoming requirements for you to do this?
>> no
>>>
>>> * If you do it what technique(s)/strategies do you use? Do you
>>> isolate encrypted content from non-encrypted content?
>> no answer
>>>
>>> * Do you know of any relevant studies/papers, etc. about this
>>> topic?
>> no answer
>>>
>>> Someone proposed that we keep each topic discussion to around 2 weeks
>>> so let's see if we've said what we want to by March 2. We can always
>>> extend this one since there was no advance notice of the topic.
>>>
>>> Thanks,
>>> Andrea
>>>
>>> Andrea Goethals
>>> Digital Preservation and Repository Services Manager
>>> Harvard Library Office for Information Systems
>>> [log in to unmask]
>>> (617) 495-3724
>>>
>>>
>>> ############################
>>>
>>> To unsubscribe from the NDSA-INFRASTRUCTURE list:
>>> write to:
>>> mailto:[log in to unmask]
>>> or click the following link:
>>>
>>> http://list.digitalpreservation.gov/SCRIPTS/WA-DIGITAL.EXE?SUBED1=NDSA-IN
>>> FRASTRUCTURE&A=1
>>
>>
>> ############################
>>
>> To unsubscribe from the NDSA-INFRASTRUCTURE list:
>> write to:
>> mailto:[log in to unmask]
>> or click the following link:
>> http://list.digitalpreservation.gov/SCRIPTS/WA-DIGITAL.EXE?SUBED1=NDSA-INF
>> RASTRUCTURE&A=1
>
> ############################
>
> To unsubscribe from the NDSA-INFRASTRUCTURE list:
> write to: mailto:[log in to unmask]
> or click the following link:
> http://list.digitalpreservation.gov/SCRIPTS/WA-DIGITAL.EXE?SUBED1=NDSA-INFRASTRUCTURE&A=1
############################
To unsubscribe from the NDSA-INFRASTRUCTURE list:
write to: mailto:[log in to unmask]
or click the following link:
http://list.digitalpreservation.gov/SCRIPTS/WA-DIGITAL.EXE?SUBED1=NDSA-INFRASTRUCTURE&A=1
