[Moims-dai] IPELTU Annex D - DPOP Checklist

Tue Apr 16 18:59:18 UTC 2019

For the version we publish, I had in mind checking boxes that are “highly recommended”?  Or perhaps “Most popular” choices?  Something to give them a starting point, and if they went to the trouble to uncheck a recommended/popular box, they would have to give some thought as to why they aren’t preserving something.  But you’re correct in pointing out that it wasn’t explained in the text.  

The intention is for it to be an informational annex only.  Not required, only an example.  An aid for an implementing program to use as a communications tool within the program.  Otherwise, programs that read IPELTU will be left with “how do I document whatever we decide to do?”  This gives them a starting point.  

On the other hand, if a program/project wants to claim… uh… adoption of (not “compliance with”) IPELTU, we could “require” them to use one of the annexes of IPELTU, or to submit a new annex (that they would also use) to be added to the IPELTU annex library.  Especially for programs/projects for which we don’t currently have an appropriate annex, that shows the world that they’re doing their best to make conscious decisions on what is/isn’t preserved.  And it helps build the library of annexes for DAI.  

*  Also a bit concerned about getting comments from other agencies about details.

The option decisions on the form are simply to check or not to check.  If an agency wants to add a new line item that applies to space missions, it’s simply added, and other programs/projects can uncheck it or delete it if they so desire.  The only purpose of us taking additional inputs from agencies/organizations pre-publication is simply for us to advise other programs that use it post-publication.  

   -=- Mike

Mike Kearney

Huntsville, Alabama, USA

From: MOIMS-DAI [mailto:moims-dai-bounces at mailman.ccsds.org] On Behalf Of garrett at his.com
Sent: Tuesday, April 16, 2019 12:50 AM
To: 'MOIMS-Data Archive Interoperability' <moims-dai at mailman.ccsds.org>
Subject: Re: [Moims-dai] IPELTU Annex D - DPOP Checklist

Hi,

Looked it over and I think it could be a good example.

I have some questions like why are some things checked and not others in the example.

What is the intention for this? Is it an Annex?  Is it Informational? Or are there any requirements in it?  Is this a required form or an example of a completed form or ??

Also a bit concerned about getting comments from other agencies about details.  I don’t really know how controversial it will get about exactly what the various options on the form are.  

Peace and joy,

-JOhn

From: MOIMS-DAI <moims-dai-bounces at mailman.ccsds.org <mailto:moims-dai-bounces at mailman.ccsds.org> > On Behalf Of Mike Kearney
Sent: Monday, April 15, 2019 6:00 PM
To: 'MOIMS-Data Archive Interoperability' <moims-dai at mailman.ccsds.org <mailto:moims-dai at mailman.ccsds.org> >
Subject: Re: [Moims-dai] IPELTU Annex D - DPOP Checklist

OK, mostly incorporated your comments, though I put in the OAIS definition of long-term as a footnote.  I’m sure the manager-level guys planning to put this on a contract will not know what “Designated Community” means, but since it is a footnote, they may not react to it, and just pass it on to the contractor.  

On the whole NASA iceberg, all I can say is “Wow.”   

   -=- Mike

Mike Kearney

Huntsville, Alabama, USA

From: MOIMS-DAI [mailto:moims-dai-bounces at mailman.ccsds.org] On Behalf Of Mark Conrad
Sent: Monday, April 15, 2019 4:29 PM
To: MOIMS-Data Archive Interoperability <moims-dai at mailman.ccsds.org <mailto:moims-dai at mailman.ccsds.org> >
Subject: Re: [Moims-dai] IPELTU Annex D - DPOP Checklist

Mike,

See attached. My comments on your comments. 

It was Item 101 that I was talking about - not Item 1. The references in Note 1 are also to Item 101.  Sorry about that! 

BTW, this particular records schedule is just the tip of the iceberg for NASA. If you are interested, take a look at  https://www.archives.gov/records-mgmt/rcs/schedules/index.html?dir=/independent-agencies/rg-0255  to see all of the NASA schedules.

Mark 

On Mon, Apr 15, 2019 at 4:48 PM Mike Kearney <kearneysolutions at gmail.com <mailto:kearneysolutions at gmail.com> > wrote:

DTOPP is nice and pronounceable, so I’m fine with that, though it seems just a little overly-directive.  Updated in the attached.  I was avoiding “Target” because Terry had issue with that term in our last telecon.  

Mark, good comments, responses in the attached.  I took issue only with the “contract” concern.   Wow, that communique from NASA to NARA is huge.  May cause me to rethink much of this.  Need more time to absorb it.  

I saw Note 1 but I couldn’t find Item 1.  I saw references to Item 1, but the items seemed to start at 101.  Can you point me to Item 1?  

   -=- Mike

Mike Kearney

Huntsville, Alabama, USA

From: MOIMS-DAI [mailto:moims-dai-bounces at mailman.ccsds.org <mailto:moims-dai-bounces at mailman.ccsds.org> ] On Behalf Of David Giaretta
Sent: Sunday, April 14, 2019 1:28 PM
To: 'MOIMS-Data Archive Interoperability' <moims-dai at mailman.ccsds.org <mailto:moims-dai at mailman.ccsds.org> >
Subject: Re: [Moims-dai] IPELTU Annex D - DPOP Checklist

Mike

Mark’s comments make sense to me.

My only comment is that since OAIS already uses “Preservation Objectives” in a specific way, we should change the name to “Digital Target of Preservation Proforma”, which would be DTOPP.

..David

From: MOIMS-DAI <moims-dai-bounces at mailman.ccsds.org <mailto:moims-dai-bounces at mailman.ccsds.org> > On Behalf Of Mark Conrad
Sent: 12 April 2019 19:35
To: MOIMS-Data Archive Interoperability <moims-dai at mailman.ccsds.org <mailto:moims-dai at mailman.ccsds.org> >
Subject: Re: [Moims-dai] IPELTU Annex D - DPOP Checklist

Mike,

Thanks for putting this together. Overall it looks very good. I have attached a version with my comments. I have also attached a records disposition schedule from NASA that lists some of the types of records that need to be retained. See especially Item 1 and Note 1. I hope this information is helpful.

Mark Conrad
NARA Information Services

Systems Engineering Division (IT)
The National Archives and Records Administration
Erma Ora Byrd Conference and Learning Center
Building 494, Room 225
610 State Route 956
Rocket Center, WV  26726

Phone: 304-726-7820
Fax: 304-726-7802
Email: mark.conrad at nara.gov <mailto:mark.conrad at nara.gov>  

On Thu, Apr 11, 2019 at 6:39 PM Mike Kearney <kearneysolutions at gmail.com <mailto:kearneysolutions at gmail.com> > wrote:

DIA WG colleagues:  In the telecon on Tuesday 4/9, we discussed my draft Annex D for IPELTU.  For those that weren’t there, my original action was to develop an annex to instruct space operations teams what data should be preserved.  I have expanded that to be an annex for spaceflight programs/projects as a whole, on the premise that at the beginning of a project we need for the top-level program/project manager to dictate to the rest of the team what will or will not be preserved, from his mission, in the long term.  So it’s no longer just operations, it’s the whole mission.  The checklist makes some pointed statements that should get the attention of management, about what results of his project are worth preserving in the long run.  In this way, it encourages early (pre-phase A?) planning and recognition that resources should be allocated for preservation.  

I’ve coined the phrase DPOP (Digital Preservation Objectives Proforma) Checklist.  After some discussion, we discarded similar terms to PICS- and ICS-Proforma to avoid any implication of “compliance” guidance.  Some discussion on “Proforma” is in the first page instructions.  The single word version (proforma vs. pro forma) is used for compatibility with other CCSDS usage.  

While this one is for space missions, I envision other DPOP Checklists as annexes for other types of endeavors.  Manufacturing, academia, oceaneering, information technology development, etc.  CCSDS does space missions, but other disciplines can be invited to create DPOP Checklists for their industry.  

So, this is a very rough draft.  Steve Hughes has agreed to try to expand section 1.5 with the experience of PDS, but of course other contributors and other comments are welcome.   

Here are a few notes:  

*         I think it’s important to keep the first page instructions limited to one page.  If it’s too long, it won’t be read or used.  It has to be something a manager can pick up and start checking/revising quickly.  

*         For Level 0, 1 and 2 processing guidance, I used this website:  http://www.srl.caltech.edu/ACE/ASC/level1/dpl_def.htm  Of course, different missions will have different terminology, so I reflected that in the first-page instructions.  

*         My intention in the check boxes is that this should be made available in Word format (perhaps from SANA) for managers to easily capture and modify for their program.  

*         Two levels of detail are represented.  High level for the managers that want only 10 or so items to check off, and let the lower level teams interpret it.  Detailed level (just barely begun) for the managers that understand what needs to be preserved, and want to manage the resources needed to preserve it.  

For discussion online and at Mountain View.  

   -=- Mike

Mike Kearney

Huntsville, Alabama, USA

_______________________________________________
MOIMS-DAI mailing list
MOIMS-DAI at mailman.ccsds.org <mailto:MOIMS-DAI at mailman.ccsds.org> 
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-dai

_______________________________________________
MOIMS-DAI mailing list
MOIMS-DAI at mailman.ccsds.org <mailto:MOIMS-DAI at mailman.ccsds.org> 
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-dai

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20190416/dd029384/attachment-0001.html>