From Nestor.Peccia at esa.int Fri Sep 4 09:56:48 2009 From: Nestor.Peccia at esa.int (Nestor.Peccia@esa.int) Date: Fri Sep 4 09:28:13 2009 Subject: [Moims-rac] [Cesg-all] Fall 2009 Meeting Room Requests Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Fall 2009 Meeting Room Request.doc Type: application/octet-stream Size: 71168 bytes Desc: not available Url : http://mailman.ccsds.org/pipermail/moims-rac/attachments/20090904/06ce5b87/Fall2009MeetingRoomRequest-0001.obj From david.giaretta at stfc.ac.uk Tue Sep 8 17:41:24 2009 From: david.giaretta at stfc.ac.uk (Giaretta, David (STFC,RAL,SSTD)) Date: Tue Sep 8 17:13:03 2009 Subject: [Moims-rac] Replacement text in Annex A Message-ID: Dear WG members I've had some discussions with the CCSDS editor and security consultant about Annex - the Security annex - specifically what security concerns arise if one uses the document. The following replacement text seems acceptable. So no change to the metrics but rather just replacement of Annex A. Please let me know as soon as possible if you have any problems with this. ..David ----------------- New text for Annex A --------- SECURITY 1 INTRODUCTION The use of the Audit and Certification standard has several potential areas of security concern. One security concern is the possibility that the repository is fooled into undergoing an archive by someone unqualified or even malicious. Another concern involves the possible release of confidential information which is collected as evidence by the auditor. 2 SECURITY CONCERNS WITH RESPECT TO THE CCSDS DOCUMENT The repository may ask someone to perform an audit using this standard. There is a possibility that the person contacted is not in fact the person that the repository believes. Alternatively the correct person may be contacted but in fact another, possibly malicious, person may turn up to perform the audit. In the process of collecting evidence for the various metrics the auditor may collect information which is confidential or sensitive, for example details of security weaknesses. There is a danger that such information may fall into the wrong hands and expose the repository to increased risk. Alternatively in the process of collecting evidence the repository system may be damaged. While these are all valid security concerns, they fall outside the purview of this standard, which applies only to the metrics which an auditor should use for auditing a repository. 3 POTENTIAL THREATS AND ATTACK SCENARIOS Impersonation of an auditor and/or release of confidential information could both result in exposing the repository and its holdings to increased risk and loss of reputation of the repository. 4 CONSEQUENCES OF NOT APPLYING SECURITY TO THE TECHNOLOGY While these security issues are of concern, they are out of scope with respect to this document. This document aims to provide the basis for an audit and certification process for assessing the trustworthiness of digital repositories. Providing protection against false auditors must rely on the repository's identification and authorisation systems. Protection against loss of confidential information in the possession of the auditor must be provided by the security system of that auditor and the method of transmission of information which is agreed between the repository and auditor. Protection against damage to the repository or its holdings during an audit must rely on the security and safety systems of the repository. -- Scanned by iCritical. From waltz at crl.edu Tue Sep 8 17:42:22 2009 From: waltz at crl.edu (Marie Waltz) Date: Tue Sep 8 17:17:25 2009 Subject: [Moims-rac] Replacement text in Annex A In-Reply-To: References: Message-ID: <9E612AEEF6ADB74A8690EC3F91B79C84017BAB47@crlexchange.LAN_DOMAIN.EDU> Hi David- Hope all is well. This looks fine to me, except that I think this is a mistake " is fooled into undergoing an archive." I think one might be fooled into an archive, but never undergoing one... -Marie -----Original Message----- From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Giaretta, David (STFC,RAL,SSTD) Sent: Tuesday, September 08, 2009 4:41 PM To: moims-rac@mailman.ccsds.org Subject: [Moims-rac] Replacement text in Annex A Dear WG members I've had some discussions with the CCSDS editor and security consultant about Annex - the Security annex - specifically what security concerns arise if one uses the document. The following replacement text seems acceptable. So no change to the metrics but rather just replacement of Annex A. Please let me know as soon as possible if you have any problems with this. ..David ----------------- New text for Annex A --------- SECURITY 1 INTRODUCTION The use of the Audit and Certification standard has several potential areas of security concern. One security concern is the possibility that the repository is fooled into undergoing an archive by someone unqualified or even malicious. Another concern involves the possible release of confidential information which is collected as evidence by the auditor. 2 SECURITY CONCERNS WITH RESPECT TO THE CCSDS DOCUMENT The repository may ask someone to perform an audit using this standard. There is a possibility that the person contacted is not in fact the person that the repository believes. Alternatively the correct person may be contacted but in fact another, possibly malicious, person may turn up to perform the audit. In the process of collecting evidence for the various metrics the auditor may collect information which is confidential or sensitive, for example details of security weaknesses. There is a danger that such information may fall into the wrong hands and expose the repository to increased risk. Alternatively in the process of collecting evidence the repository system may be damaged. While these are all valid security concerns, they fall outside the purview of this standard, which applies only to the metrics which an auditor should use for auditing a repository. 3 POTENTIAL THREATS AND ATTACK SCENARIOS Impersonation of an auditor and/or release of confidential information could both result in exposing the repository and its holdings to increased risk and loss of reputation of the repository. 4 CONSEQUENCES OF NOT APPLYING SECURITY TO THE TECHNOLOGY While these security issues are of concern, they are out of scope with respect to this document. This document aims to provide the basis for an audit and certification process for assessing the trustworthiness of digital repositories. Providing protection against false auditors must rely on the repository's identification and authorisation systems. Protection against loss of confidential information in the possession of the auditor must be provided by the security system of that auditor and the method of transmission of information which is agreed between the repository and auditor. Protection against damage to the repository or its holdings during an audit must rely on the security and safety systems of the repository. -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac From david.giaretta at stfc.ac.uk Tue Sep 8 17:51:07 2009 From: david.giaretta at stfc.ac.uk (Giaretta, David (STFC,RAL,SSTD)) Date: Tue Sep 8 17:22:21 2009 Subject: [Moims-rac] Replacement text in Annex A In-Reply-To: <9E612AEEF6ADB74A8690EC3F91B79C84017BAB47@crlexchange.LAN_DOMAIN.EDU> References: <9E612AEEF6ADB74A8690EC3F91B79C84017BAB47@crlexchange.LAN_DOMAIN.EDU> Message-ID: Oops - well spotted. I guess that should read " fooled into undergoing an audit " ..David -----Original Message----- From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Marie Waltz Sent: 08 September 2009 22:42 To: MOIMS-Repository Audit and Certification Working Group Subject: RE: [Moims-rac] Replacement text in Annex A Hi David- Hope all is well. This looks fine to me, except that I think this is a mistake " is fooled into undergoing an archive." I think one might be fooled into an archive, but never undergoing one... -Marie -----Original Message----- From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Giaretta, David (STFC,RAL,SSTD) Sent: Tuesday, September 08, 2009 4:41 PM To: moims-rac@mailman.ccsds.org Subject: [Moims-rac] Replacement text in Annex A Dear WG members I've had some discussions with the CCSDS editor and security consultant about Annex - the Security annex - specifically what security concerns arise if one uses the document. The following replacement text seems acceptable. So no change to the metrics but rather just replacement of Annex A. Please let me know as soon as possible if you have any problems with this. ..David ----------------- New text for Annex A --------- SECURITY 1 INTRODUCTION The use of the Audit and Certification standard has several potential areas of security concern. One security concern is the possibility that the repository is fooled into undergoing an archive by someone unqualified or even malicious. Another concern involves the possible release of confidential information which is collected as evidence by the auditor. 2 SECURITY CONCERNS WITH RESPECT TO THE CCSDS DOCUMENT The repository may ask someone to perform an audit using this standard. There is a possibility that the person contacted is not in fact the person that the repository believes. Alternatively the correct person may be contacted but in fact another, possibly malicious, person may turn up to perform the audit. In the process of collecting evidence for the various metrics the auditor may collect information which is confidential or sensitive, for example details of security weaknesses. There is a danger that such information may fall into the wrong hands and expose the repository to increased risk. Alternatively in the process of collecting evidence the repository system may be damaged. While these are all valid security concerns, they fall outside the purview of this standard, which applies only to the metrics which an auditor should use for auditing a repository. 3 POTENTIAL THREATS AND ATTACK SCENARIOS Impersonation of an auditor and/or release of confidential information could both result in exposing the repository and its holdings to increased risk and loss of reputation of the repository. 4 CONSEQUENCES OF NOT APPLYING SECURITY TO THE TECHNOLOGY While these security issues are of concern, they are out of scope with respect to this document. This document aims to provide the basis for an audit and certification process for assessing the trustworthiness of digital repositories. Providing protection against false auditors must rely on the repository's identification and authorisation systems. Protection against loss of confidential information in the possession of the auditor must be provided by the security system of that auditor and the method of transmission of information which is agreed between the repository and auditor. Protection against damage to the repository or its holdings during an audit must rely on the security and safety systems of the repository. -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -- Scanned by iCritical. From bambacher at verizon.net Tue Sep 8 17:51:45 2009 From: bambacher at verizon.net (bambacher@verizon.net) Date: Tue Sep 8 17:23:02 2009 Subject: [Moims-rac] Replacement text in Annex A Message-ID: <1612833087.1239597.1252446705593.JavaMail.root@vms124.mailsrvcs.net> An HTML attachment was scrubbed... URL: http://mailman.ccsds.org/pipermail/moims-rac/attachments/20090908/0047e336/attachment.html From bambacher at verizon.net Tue Sep 8 17:55:09 2009 From: bambacher at verizon.net (bambacher@verizon.net) Date: Tue Sep 8 17:26:44 2009 Subject: [Moims-rac] Replacement text in Annex A Message-ID: <859592024.1239921.1252446909149.JavaMail.root@vms124.mailsrvcs.net> An HTML attachment was scrubbed... URL: http://mailman.ccsds.org/pipermail/moims-rac/attachments/20090908/c4c58894/attachment.htm From david.giaretta at stfc.ac.uk Tue Sep 8 17:59:32 2009 From: david.giaretta at stfc.ac.uk (Giaretta, David (STFC,RAL,SSTD)) Date: Tue Sep 8 17:31:12 2009 Subject: [Moims-rac] Replacement text in Annex A In-Reply-To: <1612833087.1239597.1252446705593.JavaMail.root@vms124.mailsrvcs.net> References: <1612833087.1239597.1252446705593.JavaMail.root@vms124.mailsrvcs.net> Message-ID: Hi Bruce It is a CCSDS requirement that there is some text which addresses any security implications of actually using the standard e.g. if you use the standard and as a result there is a release of confidential documents which have been collected as evidence. Simon will be sending out the Guidelines document which needs to be completed. Then the handbook after that. Regards ..David From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of bambacher@verizon.net Sent: 08 September 2009 22:52 To: moims-rac@mailman.ccsds.org Subject: Re: [Moims-rac] Replacement text in Annex A David, I find the substitute very poorly worded. It is not acceptable from that perspective alone. I do not even understand the Introduction - its purpose or what it is saying. It also seems to be overkill. We certainly can adddress these issues in the auditor's handbook. We already addressed the possibility of keeping certain audit information restricted to avoid revealing such weaknesses. And anyone who contracts with one person/team to conduct an audit and allows someone else to perform the audit, without an acceptable explanation, deserves to be fooled. Once I understand the aims of each section I am willing to help rewrite it. When will we start working on the handbook? On Sep 8, 2009, Giaretta, David (STFC,RAL,SSTD) wrote: Dear WG members I've had some discussions with the CCSDS editor and security consultant about Annex - the Security annex - specifically what security concerns arise if one uses the document. The following replacement text seems acceptable. So no change to the metrics but rather just replacement of Annex A. Please let me know as soon as possible if you have any problems with this. ..David ----------------- New text for Annex A --------- SECURITY 1 INTRODUCTION The use of the Audit and Certification standard has several potential areas of security concern. One security concern is the possibility that the repository is fooled into undergoing an archive by someone unqualified or even malicious. Another concern involves the possible release of confidential information which is collected as evidence by the auditor. 2 SECURITY CONCERNS WITH RESPECT TO THE CCSDS DOCUMENT The repository may ask someone to perform an audit using this standard. There is a possibility that the person contacted is not in fact the person that the repository believes. Alternatively the correct person may be contacted but in fact another, possibly malicious, person may turn up to perform the audit. In the process of collecting evidence for the various metrics the auditor may collect information which is confidential or sensitive, for example details of security weaknesses. There is a danger that such information may fall into the wrong hands and expose the repository to increased risk. Alternatively in the process of collecting evidence the repository system may be damaged. While these are all valid security concerns, they fall outside the purview of this standard, which applies only to the metrics which an auditor should use for auditing a repository. 3 POTENTIAL THREATS AND ATTACK SCENARIOS Impersonation of an auditor and/or release of confidential information could both result in exposing the repository and its holdings to increased risk and loss of reputation of the repository. 4 CONSEQUENCES OF NOT APPLYING SECURITY TO THE TECHNOLOGY While these security issues are of concern, they are out of scope with respect to this document. This document aims to provide the basis for an audit and certification process for assessing the trustworthiness of digital repositories. Providing protection against false auditors must rely on the repository's identification and authorisation systems. Protection against loss of confidential information in the possession of the auditor must be provided by the security system of that auditor and the method of transmission of information which is agreed between the repository and auditor. Protection against damage to the repository or its holdings during an audit must rely on the security and safety systems of the repository. -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ccsds.org/pipermail/moims-rac/attachments/20090908/6dd86fdb/attachment.html From david.giaretta at stfc.ac.uk Tue Sep 8 18:19:09 2009 From: david.giaretta at stfc.ac.uk (Giaretta, David (STFC,RAL,SSTD)) Date: Tue Sep 8 17:50:24 2009 Subject: [Moims-rac] Replacement text in Annex A In-Reply-To: <859592024.1239921.1252446909149.JavaMail.root@vms124.mailsrvcs.net> References: <859592024.1239921.1252446909149.JavaMail.root@vms124.mailsrvcs.net> Message-ID: It?s not a question of an audit team being forced on a repository. It is considering the possibility that the repository decides to call in some reputable auditors for an audit ? what could go wrong from the security point of view? For example the repository might call AuditRUs and make an appointment but in fact someone else knocks them out, takes their place and turns up for nefarious purposes. All the revised wording says is that it?s up the repository to use its normal checks on who it lets in. Does that help? ..David From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of bambacher@verizon.net Sent: 08 September 2009 22:55 To: moims-rac@mailman.ccsds.org Subject: Re: RE: [Moims-rac] Replacement text in Annex A Isn't the audit the end result of a long interaction between the repository, the standard(s) and the audit team? Doesn't the audit only happen after the repository requests it? Doesn't a self evaluation precede an audit? I am not aware of any legislation passed or pending that requires an audit and "forces" an unknown audit team upon a repository. On Sep 8, 2009, Giaretta, David (STFC,RAL,SSTD) wrote: Oops - well spotted. I guess that should read " fooled into undergoing an audit " ..David -----Original Message----- From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Marie Waltz Sent: 08 September 2009 22:42 To: MOIMS-Repository Audit and Certification Working Group Subject: RE: [Moims-rac] Replacement text in Annex A Hi David- Hope all is well. This looks fine to me, except that I think this is a mistake " is fooled into undergoing an archive." I think one might be fooled into an archive, but never undergoing one... -Marie -----Original Message----- From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Giaretta, David (STFC,RAL,SSTD) Sent: Tuesday, September 08, 2009 4:41 PM To: moims-rac@mailman.ccsds.org Subject: [Moims-rac] Replacement text in Annex A Dear WG members I've had some discussions with the CCSDS editor and security consultant about Annex - the Security annex - specifically what security concerns arise if one uses the document. The following replacement text seems acceptable. So no change to the metrics but rather just replacement of Annex A. Please let me know as soon as possible if you have any problems with this. ..David ----------------- New text for Annex A --------- SECURITY 1 INTRODUCTION The use of the Audit and Certification standard has several potential areas of security concern. One security concern is the possibility that the repository is fooled into undergoing an archive by someone unqualified or even malicious. Another concern involves the possible release of confidential information which is collected as evidence by the auditor. 2 SECURITY CONCERNS WITH RESPECT TO THE CCSDS DOCUMENT The repository may ask someone to perform an audit using this standard. There is a possibility that the person contacted is not in fact the person that the repository believes. Alternatively the correct person may be contacted but in fact another, possibly malicious, person may turn up to perform the audit. In the process of collecting evidence for the various metrics the auditor may collect information which is confidential or sensitive, for example details of security weaknesses. There is a danger that such information may fall into the wrong hands and expose the repository to increased risk. Alternatively in the process of collecting evidence the repository system may be damaged. While these are all valid security concerns, they fall outside the purview of this standard, which applies only to the metrics which an auditor should use for auditing a repository. 3 POTENTIAL THREATS AND ATTACK SCENARIOS Impersonation of an auditor and/or release of confidential information could both result in exposing the repository and its holdings to increased risk and loss of reputation of the repository. 4 CONSEQUENCES OF NOT APPLYING SECURITY TO THE TECHNOLOGY While these security issues are of concern, they are out of scope with respect to this document. This document aims to provide the basis for an audit and certification process for assessing the trustworthiness of digital repositories. Providing protection against false auditors must rely on the repository's identification and authorisation systems. Protection against loss of confidential information in the possession of the auditor must be provided by the security system of that auditor and the method of transmission of information which is agreed between the repository and auditor. Protection against damage to the repository or its holdings during an audit must rely on the security and safety systems of the repository. -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ccsds.org/pipermail/moims-rac/attachments/20090908/ae3a3ff2/attachment.htm From tibbo at email.unc.edu Tue Sep 8 18:26:45 2009 From: tibbo at email.unc.edu (Helen Tibbo) Date: Tue Sep 8 18:35:04 2009 Subject: [Moims-rac] Replacement text in Annex A In-Reply-To: <1612833087.1239597.1252446705593.JavaMail.root@vms124.mailsrvcs.net> References: <1612833087.1239597.1252446705593.JavaMail.root@vms124.mailsrvcs.net> Message-ID: <010801ca30d3$72d22d90$587688b0$@unc.edu> Well this appears to be a CYA annex. If the language is cleaned up a bit it seems OK. Of greater concern, outside this Mission Impossible scenario, is the poor auditor and the effect of poor advice resulting in data loss. I think this too is beyond the standard. We cannot predict how people will use the standard. Some mechanics are good, some not so good; some surgeons using a standardized technique are fabulously successful, others have a poor track record. That does not mean the standard of care or the surgical technique are poor, just the application. -Helen Dr. Helen R. Tibbo School of Information and Library Science 201 Manning Hall CB#3360 University of North Carolina at Chapel Hill Chapel Hill, NC 27599-3360 Tel: 919-962-8063 Fax: 919-962-8071 Email: tibbo@email.unc.edu From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of bambacher@verizon.net Sent: Tuesday, September 08, 2009 5:52 PM To: moims-rac@mailman.ccsds.org Subject: Re: [Moims-rac] Replacement text in Annex A David, I find the substitute very poorly worded. It is not acceptable from that perspective alone. I do not even understand the Introduction - its purpose or what it is saying. It also seems to be overkill. We certainly can adddress these issues in the auditor's handbook. We already addressed the possibility of keeping certain audit information restricted to avoid revealing such weaknesses. And anyone who contracts with one person/team to conduct an audit and allows someone else to perform the audit, without an acceptable explanation, deserves to be fooled. Once I understand the aims of each section I am willing to help rewrite it. When will we start working on the handbook? On Sep 8, 2009, Giaretta, David (STFC,RAL,SSTD) wrote: Dear WG members I've had some discussions with the CCSDS editor and security consultant about Annex - the Security annex - specifically what security concerns arise if one uses the document. The following replacement text seems acceptable. So no change to the metrics but rather just replacement of Annex A. Please let me know as soon as possible if you have any problems with this. ..David ----------------- New text for Annex A --------- SECURITY 1 INTRODUCTION The use of the Audit and Certification standard has several potential areas of security concern. One security concern is the possibility that the repository is fooled into undergoing an archive by someone unqualified or even malicious. Another concern involves the possible release of confidential information which is collected as evidence by the auditor. 2 SECURITY CONCERNS WITH RESPECT TO THE CCSDS DOCUMENT The repository may ask someone to perform an audit using this standard. There is a possibility that the person contacted is not in fact the person that the repository believes. Alternatively the correct person may be contacted but in fact another, possibly malicious, person may turn up to perform the audit. In the process of collecting evidence for the various metrics the auditor may collect information which is confidential or sensitive, for example details of security weaknesses. There is a danger that such information may fall into the wrong hands and expose the repository to increased risk. Alternatively in the process of collecting evidence the repository system may be damaged. While these are all valid security concerns, they fall outside the purview of this standard, which applies only to the metrics which an auditor should use for auditing a repository. 3 POTENTIAL THREATS AND ATTACK SCENARIOS Impersonation of an auditor and/or release of confidential information could both result in exposing the repository and its holdings to increased risk and loss of reputation of the repository. 4 CONSEQUENCES OF NOT APPLYING SECURITY TO THE TECHNOLOGY While these security issues are of concern, they are out of scope with respect to this document. This document aims to provide the basis for an audit and certification process for assessing the trustworthiness of digital repositories. Providing protection against false auditors must rely on the repository's identification and authorisation systems. Protection against loss of confidential information in the possession of the auditor must be provided by the security system of that auditor and the method of transmission of information which is agreed between the repository and auditor. Protection against damage to the repository or its holdings during an audit must rely on the security and safety systems of the repository. -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ccsds.org/pipermail/moims-rac/attachments/20090908/ea908933/attachment.html From FerranteR at si.edu Tue Sep 8 21:24:36 2009 From: FerranteR at si.edu (Ferrante, Riccardo) Date: Tue Sep 8 20:56:07 2009 Subject: [Moims-rac] Replacement text in Annex A Message-ID: I agree with Helen. However, it rankles me that there is an expectation that we document that use of the standard excuses neither the archive nor the auditor from applying good, sound business practices. For example: - non-disclosure agreements. - verification of identity and credentials both at the time of contracting and at the time of the audit. - escorting the auditor when dealing with sensitive systems - requiring transparency and accountability of the auditor such as an audit plan draft. These are not valid security concerns that have anything to do with the standard and really have no place being addressed here. The same concerns can be raised when Coca-cola hires a company to upgrade their accounting system or Adobe invites individuals to engage, as non-staff, in the development and testing of a new software product or a museum allows volunteers to work in restricted areas with sensitive materials or with access to the IT network. It's hard not to be flippant about this and suggest that we replace the text with... ...When an archive invites an individual from outside the organization to examine its documents, policies, practices, and IT systems, don't be stupid... However unnecessary this may seem, I can see the value of providing some revised text just to keep this thing going forward. The last section gets to the point. On a less scarastic note, some grammatical notes: "that the repository is fooled into undergoing an archive by someone unqualified or even malicious. "... 'Archive' should be 'audit'. " There is a possibility that the person contacted is not in fact the person that the repository believes. " '...that the repository believes he or she to be.' Ricc Riccardo Ferrante Electronic Records Program Director Smithsonian Institution Archives E - FerranteR@si.edu P - 202-633-5906 F.- 202-633-5928 C - 202-341-4658 ________________________________ From: moims-rac-bounces@mailman.ccsds.org To: 'MOIMS-Repository Audit and Certification Working Group' Sent: Tue Sep 08 18:26:45 2009 Subject: RE: [Moims-rac] Replacement text in Annex A Well this appears to be a CYA annex. If the language is cleaned up a bit it seems OK. Of greater concern, outside this Mission Impossible scenario, is the poor auditor and the effect of poor advice resulting in data loss. I think this too is beyond the standard. We cannot predict how people will use the standard. Some mechanics are good, some not so good; some surgeons using a standardized technique are fabulously successful, others have a poor track record. That does not mean the standard of care or the surgical technique are poor, just the application. -Helen Dr. Helen R. Tibbo School of Information and Library Science 201 Manning Hall CB#3360 University of North Carolina at Chapel Hill Chapel Hill, NC 27599-3360 Tel: 919-962-8063 Fax: 919-962-8071 Email: tibbo@email.unc.edu From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of bambacher@verizon.net Sent: Tuesday, September 08, 2009 5:52 PM To: moims-rac@mailman.ccsds.org Subject: Re: [Moims-rac] Replacement text in Annex A David, I find the substitute very poorly worded. It is not acceptable from that perspective alone. I do not even understand the Introduction - its purpose or what it is saying. It also seems to be overkill. We certainly can adddress these issues in the auditor's handbook. We already addressed the possibility of keeping certain audit information restricted to avoid revealing such weaknesses. And anyone who contracts with one person/team to conduct an audit and allows someone else to perform the audit, without an acceptable explanation, deserves to be fooled. Once I understand the aims of each section I am willing to help rewrite it. When will we start working on the handbook? On Sep 8, 2009, Giaretta, David (STFC,RAL,SSTD) wrote: Dear WG members I've had some discussions with the CCSDS editor and security consultant about Annex - the Security annex - specifically what security concerns arise if one uses the document. The following replacement text seems acceptable. So no change to the metrics but rather just replacement of Annex A. Please let me know as soon as possible if you have any problems with this. ..David ----------------- New text for Annex A --------- SECURITY 1 INTRODUCTION The use of the Audit and Certification standard has several potential areas of security concern. One security concern is the possibility that the repository is fooled into undergoing an archive by someone unqualified or even malicious. Another concern involves the possible release of confidential information which is collected as evidence by the auditor. 2 SECURITY CONCERNS WITH RESPECT TO THE CCSDS DOCUMENT The repository may ask someone to perform an audit using this standard. There is a possibility that the person contacted is not in fact the person that the repository believes. Alternatively the correct person may be contacted but in fact another, possibly malicious, person may turn up to perform the audit. In the process of collecting evidence for the various metrics the auditor may collect information which is confidential or sensitive, for example details of security weaknesses. There is a danger that such information may fall into the wrong hands and expose the repository to increased risk. Alternatively in the process of collecting evidence the repository system may be damaged. While these are all valid security concerns, they fall outside the purview of this standard, which applies only to the metrics which an auditor should use for auditing a repository. 3 POTENTIAL THREATS AND ATTACK SCENARIOS Impersonation of an auditor and/or release of confidential information could both result in exposing the repository and its holdings to increased risk and loss of reputation of the repository. 4 CONSEQUENCES OF NOT APPLYING SECURITY TO THE TECHNOLOGY While these security issues are of concern, they are out of scope with respect to this document. This document aims to provide the basis for an audit and certification process for assessing the trustworthiness of digital repositories. Providing protection against false auditors must rely on the repository's identification and authorisation systems. Protection against loss of confidential information in the possession of the auditor must be provided by the security system of that auditor and the method of transmission of information which is agreed between the repository and auditor. Protection against damage to the repository or its holdings during an audit must rely on the security and safety systems of the repository. -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ccsds.org/pipermail/moims-rac/attachments/20090908/d8250f37/attachment.htm From Barbara.Sierman at KB.nl Wed Sep 9 04:59:57 2009 From: Barbara.Sierman at KB.nl (Barbara Sierman) Date: Wed Sep 9 04:31:06 2009 Subject: [Moims-rac] Replacement text in Annex A In-Reply-To: <010801ca30d3$72d22d90$587688b0$@unc.edu> References: <1612833087.1239597.1252446705593.JavaMail.root@vms124.mailsrvcs.net> <010801ca30d3$72d22d90$587688b0$@unc.edu> Message-ID: <68C22185DB90CA41A5ACBD8E834C5ECD05C05E00@goofy.wpakb.kb.nl> Yes I agree with Helen and with the general remarks that the repository has some responsibility when allowing an auditor on their premises. David said CCSDS requires such a paragraph, well that's ok but it should be brief. I assume other standards will have similar paragraphs? Kind regards, Barbara Sierman Digital Preservation Manager / Research and Development Koninklijke Bibliotheek PO Box 90407 2509 LK Den Haag, The Netherlands +31 70 3140109 barbara.sierman@kb.nl www.kb.nl ________________________________ Van: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] Namens Helen Tibbo Verzonden: woensdag 9 september 2009 0:27 Aan: 'MOIMS-Repository Audit and Certification Working Group' Onderwerp: RE: [Moims-rac] Replacement text in Annex A Well this appears to be a CYA annex. If the language is cleaned up a bit it seems OK. Of greater concern, outside this Mission Impossible scenario, is the poor auditor and the effect of poor advice resulting in data loss. I think this too is beyond the standard. We cannot predict how people will use the standard. Some mechanics are good, some not so good; some surgeons using a standardized technique are fabulously successful, others have a poor track record. That does not mean the standard of care or the surgical technique are poor, just the application. -Helen Dr. Helen R. Tibbo School of Information and Library Science 201 Manning Hall CB#3360 University of North Carolina at Chapel Hill Chapel Hill, NC 27599-3360 Tel: 919-962-8063 Fax: 919-962-8071 Email: tibbo@email.unc.edu From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of bambacher@verizon.net Sent: Tuesday, September 08, 2009 5:52 PM To: moims-rac@mailman.ccsds.org Subject: Re: [Moims-rac] Replacement text in Annex A David, I find the substitute very poorly worded. It is not acceptable from that perspective alone. I do not even understand the Introduction - its purpose or what it is saying. It also seems to be overkill. We certainly can adddress these issues in the auditor's handbook. We already addressed the possibility of keeping certain audit information restricted to avoid revealing such weaknesses. And anyone who contracts with one person/team to conduct an audit and allows someone else to perform the audit, without an acceptable explanation, deserves to be fooled. Once I understand the aims of each section I am willing to help rewrite it. When will we start working on the handbook? On Sep 8, 2009, Giaretta, David (STFC,RAL,SSTD) wrote: Dear WG members I've had some discussions with the CCSDS editor and security consultant about Annex - the Security annex - specifically what security concerns arise if one uses the document. The following replacement text seems acceptable. So no change to the metrics but rather just replacement of Annex A. Please let me know as soon as possible if you have any problems with this. ..David ----------------- New text for Annex A --------- SECURITY 1 INTRODUCTION The use of the Audit and Certification standard has several potential areas of security concern. One security concern is the possibility that the repository is fooled into undergoing an archive by someone unqualified or even malicious. Another concern involves the possible release of confidential information which is collected as evidence by the auditor. 2 SECURITY CONCERNS WITH RESPECT TO THE CCSDS DOCUMENT The repository may ask someone to perform an audit using this standard. There is a possibility that the person contacted is not in fact the person that the repository believes. Alternatively the correct person may be contacted but in fact another, possibly malicious, person may turn up to perform the audit. In the process of collecting evidence for the various metrics the auditor may collect information which is confidential or sensitive, for example details of security weaknesses. There is a danger that such information may fall into the wrong hands and expose the repository to increased risk. Alternatively in the process of collecting evidence the repository system may be damaged. While these are all valid security concerns, they fall outside the purview of this standard, which applies only to the metrics which an auditor should use for auditing a repository. 3 POTENTIAL THREATS AND ATTACK SCENARIOS Impersonation of an auditor and/or release of confidential information could both result in exposing the repository and its holdings to increased risk and loss of reputation of the repository. 4 CONSEQUENCES OF NOT APPLYING SECURITY TO THE TECHNOLOGY While these security issues are of concern, they are out of scope with respect to this document. This document aims to provide the basis for an audit and certification process for assessing the trustworthiness of digital repositories. Providing protection against false auditors must rely on the repository's identification and authorisation systems. Protection against loss of confidential information in the possession of the auditor must be provided by the security system of that auditor and the method of transmission of information which is agreed between the repository and auditor. Protection against damage to the repository or its holdings during an audit must rely on the security and safety systems of the repository. -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ccsds.org/pipermail/moims-rac/attachments/20090909/9f1dc4bb/attachment.htm From david.giaretta at stfc.ac.uk Wed Sep 9 05:16:34 2009 From: david.giaretta at stfc.ac.uk (Giaretta, David (STFC,RAL,SSTD)) Date: Wed Sep 9 04:47:51 2009 Subject: [Moims-rac] Replacement text in Annex A In-Reply-To: <68C22185DB90CA41A5ACBD8E834C5ECD05C05E00@goofy.wpakb.kb.nl> References: <1612833087.1239597.1252446705593.JavaMail.root@vms124.mailsrvcs.net><010801ca30d3$72d22d90$587688b0$@unc.edu> <68C22185DB90CA41A5ACBD8E834C5ECD05C05E00@goofy.wpakb.kb.nl> Message-ID: CYA - yes because we really are just saying that these things are outside the remit of the standard. It's just flagging up that - if/when someone does use the standard - they had better give some thought to some additional points. I must admit I groaned when I was asked to do this by CCSDS, because I could see perfectly well that it is valuable for communications protocols and the like but surely not for what RAC is doing. However I did in the end see the point that, apart from the CYA aspect, it was an interesting line of thought that could be valuable for people using the standard and that could be expressed fairly briefly, could be agreed relatively painlessly with the security experts of CCSDS, and which did not touch the real content of the document. All standards now going through CCSDS have to have something that shows that the security aspects related to using the standard have been thought about, and the wording has to be run past the security people in CCSDS. So I hope I and the CCSDS editor can tidy up the language and correct some typos and get it through. Regards ..David From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Barbara Sierman Sent: 09 September 2009 10:00 To: MOIMS-Repository Audit and Certification Working Group Subject: RE: [Moims-rac] Replacement text in Annex A Yes I agree with Helen and with the general remarks that the repository has some responsibility when allowing an auditor on their premises. David said CCSDS requires such a paragraph, well that's ok but it should be brief. I assume other standards will have similar paragraphs? Kind regards, Barbara Sierman Digital Preservation Manager / Research and Development Koninklijke Bibliotheek PO Box 90407 2509 LK Den Haag, The Netherlands +31 70 3140109 barbara.sierman@kb.nl www.kb.nl ________________________________ Van: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] Namens Helen Tibbo Verzonden: woensdag 9 september 2009 0:27 Aan: 'MOIMS-Repository Audit and Certification Working Group' Onderwerp: RE: [Moims-rac] Replacement text in Annex A Well this appears to be a CYA annex. If the language is cleaned up a bit it seems OK. Of greater concern, outside this Mission Impossible scenario, is the poor auditor and the effect of poor advice resulting in data loss. I think this too is beyond the standard. We cannot predict how people will use the standard. Some mechanics are good, some not so good; some surgeons using a standardized technique are fabulously successful, others have a poor track record. That does not mean the standard of care or the surgical technique are poor, just the application. -Helen Dr. Helen R. Tibbo School of Information and Library Science 201 Manning Hall CB#3360 University of North Carolina at Chapel Hill Chapel Hill, NC 27599-3360 Tel: 919-962-8063 Fax: 919-962-8071 Email: tibbo@email.unc.edu From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of bambacher@verizon.net Sent: Tuesday, September 08, 2009 5:52 PM To: moims-rac@mailman.ccsds.org Subject: Re: [Moims-rac] Replacement text in Annex A David, I find the substitute very poorly worded. It is not acceptable from that perspective alone. I do not even understand the Introduction - its purpose or what it is saying. It also seems to be overkill. We certainly can adddress these issues in the auditor's handbook. We already addressed the possibility of keeping certain audit information restricted to avoid revealing such weaknesses. And anyone who contracts with one person/team to conduct an audit and allows someone else to perform the audit, without an acceptable explanation, deserves to be fooled. Once I understand the aims of each section I am willing to help rewrite it. When will we start working on the handbook? On Sep 8, 2009, Giaretta, David (STFC,RAL,SSTD) wrote: Dear WG members I've had some discussions with the CCSDS editor and security consultant about Annex - the Security annex - specifically what security concerns arise if one uses the document. The following replacement text seems acceptable. So no change to the metrics but rather just replacement of Annex A. Please let me know as soon as possible if you have any problems with this. ..David ----------------- New text for Annex A --------- SECURITY 1 INTRODUCTION The use of the Audit and Certification standard has several potential areas of security concern. One security concern is the possibility that the repository is fooled into undergoing an archive by someone unqualified or even malicious. Another concern involves the possible release of confidential information which is collected as evidence by the auditor. 2 SECURITY CONCERNS WITH RESPECT TO THE CCSDS DOCUMENT The repository may ask someone to perform an audit using this standard. There is a possibility that the person contacted is not in fact the person that the repository believes. Alternatively the correct person may be contacted but in fact another, possibly malicious, person may turn up to perform the audit. In the process of collecting evidence for the various metrics the auditor may collect information which is confidential or sensitive, for example details of security weaknesses. There is a danger that such information may fall into the wrong hands and expose the repository to increased risk. Alternatively in the process of collecting evidence the repository system may be damaged. While these are all valid security concerns, they fall outside the purview of this standard, which applies only to the metrics which an auditor should use for auditing a repository. 3 POTENTIAL THREATS AND ATTACK SCENARIOS Impersonation of an auditor and/or release of confidential information could both result in exposing the repository and its holdings to increased risk and loss of reputation of the repository. 4 CONSEQUENCES OF NOT APPLYING SECURITY TO THE TECHNOLOGY While these security issues are of concern, they are out of scope with respect to this document. This document aims to provide the basis for an audit and certification process for assessing the trustworthiness of digital repositories. Providing protection against false auditors must rely on the repository's identification and authorisation systems. Protection against loss of confidential information in the possession of the auditor must be provided by the security system of that auditor and the method of transmission of information which is agreed between the repository and auditor. Protection against damage to the repository or its holdings during an audit must rely on the security and safety systems of the repository. -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -- Scanned by iCritical. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ccsds.org/pipermail/moims-rac/attachments/20090909/53aaf07d/attachment.html From david.giaretta at stfc.ac.uk Wed Sep 9 05:21:56 2009 From: david.giaretta at stfc.ac.uk (Giaretta, David (STFC,RAL,SSTD)) Date: Wed Sep 9 04:53:38 2009 Subject: [Moims-rac] Replacement text in Annex A In-Reply-To: References: Message-ID: OK ? will update. I just replied to Barbara and Helen. I think we?re saying the same thing! ..David From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Ferrante, Riccardo Sent: 09 September 2009 02:25 To: moims-rac@mailman.ccsds.org Subject: Re: [Moims-rac] Replacement text in Annex A I agree with Helen. However, it rankles me that there is an expectation that we document that use of the standard excuses neither the archive nor the auditor from applying good, sound business practices. For example: - non-disclosure agreements. - verification of identity and credentials both at the time of contracting and at the time of the audit. - escorting the auditor when dealing with sensitive systems - requiring transparency and accountability of the auditor such as an audit plan draft. These are not valid security concerns that have anything to do with the standard and really have no place being addressed here. The same concerns can be raised when Coca-cola hires a company to upgrade their accounting system or Adobe invites individuals to engage, as non-staff, in the development and testing of a new software product or a museum allows volunteers to work in restricted areas with sensitive materials or with access to the IT network. It's hard not to be flippant about this and suggest that we replace the text with... ...When an archive invites an individual from outside the organization to examine its documents, policies, practices, and IT systems, don't be stupid... However unnecessary this may seem, I can see the value of providing some revised text just to keep this thing going forward. The last section gets to the point. On a less scarastic note, some grammatical notes: "that the repository is fooled into undergoing an archive by someone unqualified or even malicious. "... 'Archive' should be 'audit'. " There is a possibility that the person contacted is not in fact the person that the repository believes. " '...that the repository believes he or she to be.' Ricc Riccardo Ferrante Electronic Records Program Director Smithsonian Institution Archives E - FerranteR@si.edu P - 202-633-5906 F.- 202-633-5928 C - 202-341-4658 ________________________________ From: moims-rac-bounces@mailman.ccsds.org To: 'MOIMS-Repository Audit and Certification Working Group' Sent: Tue Sep 08 18:26:45 2009 Subject: RE: [Moims-rac] Replacement text in Annex A Well this appears to be a CYA annex. If the language is cleaned up a bit it seems OK. Of greater concern, outside this Mission Impossible scenario, is the poor auditor and the effect of poor advice resulting in data loss. I think this too is beyond the standard. We cannot predict how people will use the standard. Some mechanics are good, some not so good; some surgeons using a standardized technique are fabulously successful, others have a poor track record. That does not mean the standard of care or the surgical technique are poor, just the application. -Helen Dr. Helen R. Tibbo School of Information and Library Science 201 Manning Hall CB#3360 University of North Carolina at Chapel Hill Chapel Hill, NC 27599-3360 Tel: 919-962-8063 Fax: 919-962-8071 Email: tibbo@email.unc.edu From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of bambacher@verizon.net Sent: Tuesday, September 08, 2009 5:52 PM To: moims-rac@mailman.ccsds.org Subject: Re: [Moims-rac] Replacement text in Annex A David, I find the substitute very poorly worded. It is not acceptable from that perspective alone. I do not even understand the Introduction - its purpose or what it is saying. It also seems to be overkill. We certainly can adddress these issues in the auditor's handbook. We already addressed the possibility of keeping certain audit information restricted to avoid revealing such weaknesses. And anyone who contracts with one person/team to conduct an audit and allows someone else to perform the audit, without an acceptable explanation, deserves to be fooled. Once I understand the aims of each section I am willing to help rewrite it. When will we start working on the handbook? On Sep 8, 2009, Giaretta, David (STFC,RAL,SSTD) wrote: Dear WG members I've had some discussions with the CCSDS editor and security consultant about Annex - the Security annex - specifically what security concerns arise if one uses the document. The following replacement text seems acceptable. So no change to the metrics but rather just replacement of Annex A. Please let me know as soon as possible if you have any problems with this. ..David ----------------- New text for Annex A --------- SECURITY 1 INTRODUCTION The use of the Audit and Certification standard has several potential areas of security concern. One security concern is the possibility that the repository is fooled into undergoing an archive by someone unqualified or even malicious. Another concern involves the possible release of confidential information which is collected as evidence by the auditor. 2 SECURITY CONCERNS WITH RESPECT TO THE CCSDS DOCUMENT The repository may ask someone to perform an audit using this standard. There is a possibility that the person contacted is not in fact the person that the repository believes. Alternatively the correct person may be contacted but in fact another, possibly malicious, person may turn up to perform the audit. In the process of collecting evidence for the various metrics the auditor may collect information which is confidential or sensitive, for example details of security weaknesses. There is a danger that such information may fall into the wrong hands and expose the repository to increased risk. Alternatively in the process of collecting evidence the repository system may be damaged. While these are all valid security concerns, they fall outside the purview of this standard, which applies only to the metrics which an auditor should use for auditing a repository. 3 POTENTIAL THREATS AND ATTACK SCENARIOS Impersonation of an auditor and/or release of confidential information could both result in exposing the repository and its holdings to increased risk and loss of reputation of the repository. 4 CONSEQUENCES OF NOT APPLYING SECURITY TO THE TECHNOLOGY While these security issues are of concern, they are out of scope with respect to this document. This document aims to provide the basis for an audit and certification process for assessing the trustworthiness of digital repositories. Providing protection against false auditors must rely on the repository's identification and authorisation systems. Protection against loss of confidential information in the possession of the auditor must be provided by the security system of that auditor and the method of transmission of information which is agreed between the repository and auditor. Protection against damage to the repository or its holdings during an audit must rely on the security and safety systems of the repository. -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ccsds.org/pipermail/moims-rac/attachments/20090909/78e04abb/attachment.htm From david.giaretta at stfc.ac.uk Wed Sep 9 05:34:02 2009 From: david.giaretta at stfc.ac.uk (Giaretta, David (STFC,RAL,SSTD)) Date: Wed Sep 9 05:05:35 2009 Subject: [Moims-rac] CCSDS meeting in ESTEC/ESA, Noordwijk, The Netherlands Message-ID: The CCSDS meetings are going to be held in ESA/ESTEC, Noordwijk in the Netherlands in the week of 26-30 October. Will any of the WG be able to travel there? I guess this really is a question for those based in and around the Netherlands, since there is no funding. I was thinking that it might be valuable for those who can make it to get together on Wednesday 27th for a general discussion about strategy in the morning and then hold a telecom with the rest of the group in the afternoon. Please let me know ASAP if you plan to attend, so I can book an appropriate room. Regards ..David -- Scanned by iCritical. From FerranteR at si.edu Wed Sep 9 07:36:09 2009 From: FerranteR at si.edu (Ferrante, Riccardo) Date: Wed Sep 9 07:08:10 2009 Subject: [Moims-rac] Replacement text in Annex A Message-ID: We are. Riccardo Ferrante Electronic Records Program Director Smithsonian Institution Archives E - FerranteR@si.edu P - 202-633-5906 F.- 202-633-5928 C - 202-341-4658 ________________________________ From: moims-rac-bounces@mailman.ccsds.org To: moims-rac@mailman.ccsds.org Sent: Wed Sep 09 05:21:56 2009 Subject: RE: [Moims-rac] Replacement text in Annex A OK ? will update. I just replied to Barbara and Helen. I think we?re saying the same thing! ..David From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Ferrante, Riccardo Sent: 09 September 2009 02:25 To: moims-rac@mailman.ccsds.org Subject: Re: [Moims-rac] Replacement text in Annex A I agree with Helen. However, it rankles me that there is an expectation that we document that use of the standard excuses neither the archive nor the auditor from applying good, sound business practices. For example: - non-disclosure agreements. - verification of identity and credentials both at the time of contracting and at the time of the audit. - escorting the auditor when dealing with sensitive systems - requiring transparency and accountability of the auditor such as an audit plan draft. These are not valid security concerns that have anything to do with the standard and really have no place being addressed here. The same concerns can be raised when Coca-cola hires a company to upgrade their accounting system or Adobe invites individuals to engage, as non-staff, in the development and testing of a new software product or a museum allows volunteers to work in restricted areas with sensitive materials or with access to the IT network. It's hard not to be flippant about this and suggest that we replace the text with... ...When an archive invites an individual from outside the organization to examine its documents, policies, practices, and IT systems, don't be stupid... However unnecessary this may seem, I can see the value of providing some revised text just to keep this thing going forward. The last section gets to the point. On a less scarastic note, some grammatical notes: "that the repository is fooled into undergoing an archive by someone unqualified or even malicious. "... 'Archive' should be 'audit'. " There is a possibility that the person contacted is not in fact the person that the repository believes. " '...that the repository believes he or she to be.' Ricc Riccardo Ferrante Electronic Records Program Director Smithsonian Institution Archives E - FerranteR@si.edu P - 202-633-5906 F.- 202-633-5928 C - 202-341-4658 ________________________________ From: moims-rac-bounces@mailman.ccsds.org To: 'MOIMS-Repository Audit and Certification Working Group' Sent: Tue Sep 08 18:26:45 2009 Subject: RE: [Moims-rac] Replacement text in Annex A Well this appears to be a CYA annex. If the language is cleaned up a bit it seems OK. Of greater concern, outside this Mission Impossible scenario, is the poor auditor and the effect of poor advice resulting in data loss. I think this too is beyond the standard. We cannot predict how people will use the standard. Some mechanics are good, some not so good; some surgeons using a standardized technique are fabulously successful, others have a poor track record. That does not mean the standard of care or the surgical technique are poor, just the application. -Helen Dr. Helen R. Tibbo School of Information and Library Science 201 Manning Hall CB#3360 University of North Carolina at Chapel Hill Chapel Hill, NC 27599-3360 Tel: 919-962-8063 Fax: 919-962-8071 Email: tibbo@email.unc.edu From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of bambacher@verizon.net Sent: Tuesday, September 08, 2009 5:52 PM To: moims-rac@mailman.ccsds.org Subject: Re: [Moims-rac] Replacement text in Annex A David, I find the substitute very poorly worded. It is not acceptable from that perspective alone. I do not even understand the Introduction - its purpose or what it is saying. It also seems to be overkill. We certainly can adddress these issues in the auditor's handbook. We already addressed the possibility of keeping certain audit information restricted to avoid revealing such weaknesses. And anyone who contracts with one person/team to conduct an audit and allows someone else to perform the audit, without an acceptable explanation, deserves to be fooled. Once I understand the aims of each section I am willing to help rewrite it. When will we start working on the handbook? On Sep 8, 2009, Giaretta, David (STFC,RAL,SSTD) wrote: Dear WG members I've had some discussions with the CCSDS editor and security consultant about Annex - the Security annex - specifically what security concerns arise if one uses the document. The following replacement text seems acceptable. So no change to the metrics but rather just replacement of Annex A. Please let me know as soon as possible if you have any problems with this. ..David ----------------- New text for Annex A --------- SECURITY 1 INTRODUCTION The use of the Audit and Certification standard has several potential areas of security concern. One security concern is the possibility that the repository is fooled into undergoing an archive by someone unqualified or even malicious. Another concern involves the possible release of confidential information which is collected as evidence by the auditor. 2 SECURITY CONCERNS WITH RESPECT TO THE CCSDS DOCUMENT The repository may ask someone to perform an audit using this standard. There is a possibility that the person contacted is not in fact the person that the repository believes. Alternatively the correct person may be contacted but in fact another, possibly malicious, person may turn up to perform the audit. In the process of collecting evidence for the various metrics the auditor may collect information which is confidential or sensitive, for example details of security weaknesses. There is a danger that such information may fall into the wrong hands and expose the repository to increased risk. Alternatively in the process of collecting evidence the repository system may be damaged. While these are all valid security concerns, they fall outside the purview of this standard, which applies only to the metrics which an auditor should use for auditing a repository. 3 POTENTIAL THREATS AND ATTACK SCENARIOS Impersonation of an auditor and/or release of confidential information could both result in exposing the repository and its holdings to increased risk and loss of reputation of the repository. 4 CONSEQUENCES OF NOT APPLYING SECURITY TO THE TECHNOLOGY While these security issues are of concern, they are out of scope with respect to this document. This document aims to provide the basis for an audit and certification process for assessing the trustworthiness of digital repositories. Providing protection against false auditors must rely on the repository's identification and authorisation systems. Protection against loss of confidential information in the possession of the auditor must be provided by the security system of that auditor and the method of transmission of information which is agreed between the repository and auditor. Protection against damage to the repository or its holdings during an audit must rely on the security and safety systems of the repository. -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ccsds.org/pipermail/moims-rac/attachments/20090909/3e43f749/attachment-0001.htm From m.guercio at mclink.it Wed Sep 9 09:58:50 2009 From: m.guercio at mclink.it (Maria Guercio) Date: Wed Sep 9 09:30:02 2009 Subject: [Moims-rac] Transfer of money for CASPAR Message-ID: <1.3.200909091558.71027@mclink.it> Dear David I have now the picture complete for the funds: I will spend 410.000 euros. I need 30.000 euros as soon as possible to be able to pay Lou Reich invoices for 40.000 euros more before the end of September. I have to receive the invoices from CSC before September 22. After that date I will not be able to sign for payment. Can you inform Lou? Do you have the new email of Reagan Moore. I know that he moved from S. Diego to North Carolina, but I do not have his new email. Mariella From m.guercio at mclink.it Wed Sep 9 10:06:03 2009 From: m.guercio at mclink.it (Maria Guercio) Date: Wed Sep 9 09:37:20 2009 Subject: [Moims-rac] address of Reagan Moore Message-ID: <1.3.200909091606.81483@mclink.it> Dear Helen I need the email address of Reagan for a payment related to Caspar. I do not know if the old one is still working Can you help me? Mariella From c.rusbridge at ed.ac.uk Wed Sep 9 12:00:50 2009 From: c.rusbridge at ed.ac.uk (Chris Rusbridge) Date: Wed Sep 9 11:32:03 2009 Subject: [Moims-rac] Replacement text in Annex A In-Reply-To: <68C22185DB90CA41A5ACBD8E834C5ECD05C05E00@goofy.wpakb.kb.nl> References: <1612833087.1239597.1252446705593.JavaMail.root@vms124.mailsrvcs.net> <010801ca30d3$72d22d90$587688b0$@unc.edu> <68C22185DB90CA41A5ACBD8E834C5ECD05C05E00@goofy.wpakb.kb.nl> Message-ID: This certainly does appear to be a bit of bureaucratic nonsense, and I agree that any statement should be briefer; something to the effect that an audit may require disclosure of confidential information, and agreements must be in place to protect that information. The "man in the middle" attack scenario is far-fetched and can be discounted. I note that the OAIS revision candidate document (Pink book) that I have contains no such annex or statement. And the CCSDS Publications manual (2005 edition) does not contain the word "security"! -- Chris Rusbridge Director, Digital Curation Centre Email: c.rusbridge@ed.ac.uk Phone 0131 6513823 University of Edinburgh Appleton Tower, Crichton St, Edinburgh EH8 9LE 5th International Digital Curation Conference: "Moving to Multi-Scale Science," London, 2-4 December The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. On 9 Sep 2009, at 09:59, Barbara Sierman wrote: > Yes I agree with Helen and with the general remarks that the > repository has some responsibility when allowing an auditor on > their premises. David said CCSDS requires such a paragraph, well > that?s ok but it should be brief. I assume other standards will > have similar paragraphs? > > > > Kind regards, > > > Barbara Sierman > Digital Preservation Manager / Research and Development > > Koninklijke Bibliotheek > PO Box 90407 > 2509 LK Den Haag, The Netherlands > > +31 70 3140109 > barbara.sierman@kb.nl > > www.kb.nl > > Van: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac- > bounces@mailman.ccsds.org] Namens Helen Tibbo > Verzonden: woensdag 9 september 2009 0:27 > Aan: 'MOIMS-Repository Audit and Certification Working Group' > Onderwerp: RE: [Moims-rac] Replacement text in Annex A > > > > Well this appears to be a CYA annex. If the language is cleaned up > a bit it seems OK. Of greater concern, outside this Mission > Impossible scenario, is the poor auditor and the effect of poor > advice resulting in data loss. I think this too is beyond the > standard. We cannot predict how people will use the standard. Some > mechanics are good, some not so good; some surgeons using a > standardized technique are fabulously successful, others have a > poor track record. That does not mean the standard of care or the > surgical technique are poor, just the application. -Helen > > > > Dr. Helen R. Tibbo > > School of Information and Library Science > > 201 Manning Hall CB#3360 > > University of North Carolina at Chapel Hill Chapel Hill, NC 27599-3360 > > Tel: 919-962-8063 > > Fax: 919-962-8071 > > Email: tibbo@email.unc.edu > > > > > > From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac- > bounces@mailman.ccsds.org] On Behalf Of bambacher@verizon.net > Sent: Tuesday, September 08, 2009 5:52 PM > To: moims-rac@mailman.ccsds.org > Subject: Re: [Moims-rac] Replacement text in Annex A > > > > David, > I find the substitute very poorly worded. It is not acceptable > from that perspective alone. > > I do not even understand the Introduction - its purpose or what it > is saying. It also seems to be overkill. We certainly can > adddress these issues in the auditor's handbook. We already > addressed the possibility of keeping certain audit information > restricted to avoid revealing such weaknesses. And anyone who > contracts with one person/team to conduct an audit and allows > someone else to perform the audit, without an acceptable > explanation, deserves to be fooled. > > Once I understand the aims of each section I am willing to help > rewrite it. > > When will we start working on the handbook? > > On Sep 8, 2009, Giaretta, David (STFC,RAL,SSTD) > wrote: > > Dear WG members > > I've had some discussions with the CCSDS editor and security > consultant > about Annex - the Security annex - specifically what security concerns > arise if one uses the document. The following replacement text seems > acceptable. So no change to the metrics but rather just replacement of > Annex A. > > Please let me know as soon as possible if you have any problems with > this. > > ..David > > ----------------- New text for Annex A --------- > > SECURITY > 1 INTRODUCTION > The use of the Audit and Certification standard has several potential > areas of security concern. > One security concern is the possibility that the repository is fooled > into undergoing an archive by someone unqualified or even malicious. > Another concern involves the possible release of confidential > information which is collected as evidence by the auditor. > > 2 SECURITY CONCERNS WITH RESPECT TO THE CCSDS DOCUMENT > The repository may ask someone to perform an audit using this > standard. > There is a possibility that the person contacted is not in fact the > person that the repository believes. Alternatively the correct person > may be contacted but in fact another, possibly malicious, person may > turn up to perform the audit. > In the process of collecting evidence for the various metrics the > auditor may collect information which is confidential or sensitive, > for > example details of security weaknesses. > There is a danger that such information may fall into the wrong hands > and expose the repository to increased risk. Alternatively in the > process of collecting evidence the repository system may be damaged. > While these are all valid security concerns, they fall outside the > purview of this standard, which applies only to the metrics which an > auditor should use for auditing a repository. > > 3 POTENTIAL THREATS AND ATTACK SCENARIOS > Impersonation of an auditor and/or release of confidential information > could both result in exposing the repository and its holdings to > increased risk and loss of reputation of the repository. > > 4 CONSEQUENCES OF NOT APPLYING SECURITY TO THE TECHNOLOGY > While these security issues are of concern, they are out of scope with > respect to this document. This document aims to provide the basis > for an > audit and certification process for assessing the trustworthiness of > digital repositories. Providing protection against false auditors must > rely on the repository's identification and authorisation systems. > Protection against loss of confidential information in the > possession of > the auditor must be provided by the security system of that auditor > and > the method of transmission of information which is agreed between the > repository and auditor. Protection against damage to the repository or > its holdings during an audit must rely on the security and safety > systems of the repository. > -- > Scanned by iCritical. > > _______________________________________________ > Moims-rac mailing list > Moims-rac@mailman.ccsds.org > http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac > > _______________________________________________ > Moims-rac mailing list > Moims-rac@mailman.ccsds.org > http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac From david.giaretta at stfc.ac.uk Wed Sep 9 12:08:56 2009 From: david.giaretta at stfc.ac.uk (Giaretta, David (STFC,RAL,SSTD)) Date: Wed Sep 9 11:40:12 2009 Subject: [Moims-rac] Replacement text in Annex A In-Reply-To: References: <1612833087.1239597.1252446705593.JavaMail.root@vms124.mailsrvcs.net><010801ca30d3$72d22d90$587688b0$@unc.edu><68C22185DB90CA41A5ACBD8E834C5ECD05C05E00@goofy.wpakb.kb.nl> Message-ID: OAIS benefits from a "grandfather" clause. The CCSDS Pub Manual is being updated even now. -----Original Message----- From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Chris Rusbridge Sent: 09 September 2009 17:01 To: MOIMS-Repository Audit and Certification Working Group Subject: Re: [Moims-rac] Replacement text in Annex A This certainly does appear to be a bit of bureaucratic nonsense, and I agree that any statement should be briefer; something to the effect that an audit may require disclosure of confidential information, and agreements must be in place to protect that information. The "man in the middle" attack scenario is far-fetched and can be discounted. I note that the OAIS revision candidate document (Pink book) that I have contains no such annex or statement. And the CCSDS Publications manual (2005 edition) does not contain the word "security"! -- Chris Rusbridge Director, Digital Curation Centre Email: c.rusbridge@ed.ac.uk Phone 0131 6513823 University of Edinburgh Appleton Tower, Crichton St, Edinburgh EH8 9LE 5th International Digital Curation Conference: "Moving to Multi-Scale Science," London, 2-4 December The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. On 9 Sep 2009, at 09:59, Barbara Sierman wrote: > Yes I agree with Helen and with the general remarks that the > repository has some responsibility when allowing an auditor on > their premises. David said CCSDS requires such a paragraph, well > that's ok but it should be brief. I assume other standards will > have similar paragraphs? > > > > Kind regards, > > > Barbara Sierman > Digital Preservation Manager / Research and Development > > Koninklijke Bibliotheek > PO Box 90407 > 2509 LK Den Haag, The Netherlands > > +31 70 3140109 > barbara.sierman@kb.nl > > www.kb.nl > > Van: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac- > bounces@mailman.ccsds.org] Namens Helen Tibbo > Verzonden: woensdag 9 september 2009 0:27 > Aan: 'MOIMS-Repository Audit and Certification Working Group' > Onderwerp: RE: [Moims-rac] Replacement text in Annex A > > > > Well this appears to be a CYA annex. If the language is cleaned up > a bit it seems OK. Of greater concern, outside this Mission > Impossible scenario, is the poor auditor and the effect of poor > advice resulting in data loss. I think this too is beyond the > standard. We cannot predict how people will use the standard. Some > mechanics are good, some not so good; some surgeons using a > standardized technique are fabulously successful, others have a > poor track record. That does not mean the standard of care or the > surgical technique are poor, just the application. -Helen > > > > Dr. Helen R. Tibbo > > School of Information and Library Science > > 201 Manning Hall CB#3360 > > University of North Carolina at Chapel Hill Chapel Hill, NC 27599-3360 > > Tel: 919-962-8063 > > Fax: 919-962-8071 > > Email: tibbo@email.unc.edu > > > > > > From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac- > bounces@mailman.ccsds.org] On Behalf Of bambacher@verizon.net > Sent: Tuesday, September 08, 2009 5:52 PM > To: moims-rac@mailman.ccsds.org > Subject: Re: [Moims-rac] Replacement text in Annex A > > > > David, > I find the substitute very poorly worded. It is not acceptable > from that perspective alone. > > I do not even understand the Introduction - its purpose or what it > is saying. It also seems to be overkill. We certainly can > adddress these issues in the auditor's handbook. We already > addressed the possibility of keeping certain audit information > restricted to avoid revealing such weaknesses. And anyone who > contracts with one person/team to conduct an audit and allows > someone else to perform the audit, without an acceptable > explanation, deserves to be fooled. > > Once I understand the aims of each section I am willing to help > rewrite it. > > When will we start working on the handbook? > > On Sep 8, 2009, Giaretta, David (STFC,RAL,SSTD) > wrote: > > Dear WG members > > I've had some discussions with the CCSDS editor and security > consultant > about Annex - the Security annex - specifically what security concerns > arise if one uses the document. The following replacement text seems > acceptable. So no change to the metrics but rather just replacement of > Annex A. > > Please let me know as soon as possible if you have any problems with > this. > > ..David > > ----------------- New text for Annex A --------- > > SECURITY > 1 INTRODUCTION > The use of the Audit and Certification standard has several potential > areas of security concern. > One security concern is the possibility that the repository is fooled > into undergoing an archive by someone unqualified or even malicious. > Another concern involves the possible release of confidential > information which is collected as evidence by the auditor. > > 2 SECURITY CONCERNS WITH RESPECT TO THE CCSDS DOCUMENT > The repository may ask someone to perform an audit using this > standard. > There is a possibility that the person contacted is not in fact the > person that the repository believes. Alternatively the correct person > may be contacted but in fact another, possibly malicious, person may > turn up to perform the audit. > In the process of collecting evidence for the various metrics the > auditor may collect information which is confidential or sensitive, > for > example details of security weaknesses. > There is a danger that such information may fall into the wrong hands > and expose the repository to increased risk. Alternatively in the > process of collecting evidence the repository system may be damaged. > While these are all valid security concerns, they fall outside the > purview of this standard, which applies only to the metrics which an > auditor should use for auditing a repository. > > 3 POTENTIAL THREATS AND ATTACK SCENARIOS > Impersonation of an auditor and/or release of confidential information > could both result in exposing the repository and its holdings to > increased risk and loss of reputation of the repository. > > 4 CONSEQUENCES OF NOT APPLYING SECURITY TO THE TECHNOLOGY > While these security issues are of concern, they are out of scope with > respect to this document. This document aims to provide the basis > for an > audit and certification process for assessing the trustworthiness of > digital repositories. Providing protection against false auditors must > rely on the repository's identification and authorisation systems. > Protection against loss of confidential information in the > possession of > the auditor must be provided by the security system of that auditor > and > the method of transmission of information which is agreed between the > repository and auditor. Protection against damage to the repository or > its holdings during an audit must rely on the security and safety > systems of the repository. > -- > Scanned by iCritical. > > _______________________________________________ > Moims-rac mailing list > Moims-rac@mailman.ccsds.org > http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac > > _______________________________________________ > Moims-rac mailing list > Moims-rac@mailman.ccsds.org > http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -- Scanned by iCritical. From rdowns at ciesin.columbia.edu Wed Sep 9 12:18:01 2009 From: rdowns at ciesin.columbia.edu (Robert R. Downs) Date: Wed Sep 9 11:50:36 2009 Subject: [Moims-rac] Replacement text in Annex A In-Reply-To: References: <1612833087.1239597.1252446705593.JavaMail.root@vms124.mailsrvcs.net><010801ca30d3$72d22d90$587688b0$@unc.edu><68C22185DB90CA41A5ACBD8E834C5ECD05C05E00@goofy.wpakb.kb.nl> Message-ID: <4AA7D539.9020304@ciesin.columbia.edu> To move forward, I suggest that we include the proposed statements for Annex A, revising the text to include the phrasing changes that have been offered for improvement. Thanks, Bob Giaretta, David (STFC,RAL,SSTD) wrote: > OAIS benefits from a "grandfather" clause. > > The CCSDS Pub Manual is being updated even now. > > > -----Original Message----- > From: moims-rac-bounces@mailman.ccsds.org > [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Chris > Rusbridge > Sent: 09 September 2009 17:01 > To: MOIMS-Repository Audit and Certification Working Group > Subject: Re: [Moims-rac] Replacement text in Annex A > > This certainly does appear to be a bit of bureaucratic nonsense, and > I agree that any statement should be briefer; something to the effect > that an audit may require disclosure of confidential information, and > agreements must be in place to protect that information. The "man in > the middle" attack scenario is far-fetched and can be discounted. > > I note that the OAIS revision candidate document (Pink book) that I > have contains no such annex or statement. And the CCSDS Publications > manual (2005 edition) does not contain the word "security"! > > -- > Chris Rusbridge > Director, Digital Curation Centre > Email: c.rusbridge@ed.ac.uk Phone 0131 6513823 > University of Edinburgh > Appleton Tower, Crichton St, Edinburgh EH8 9LE > > 5th International Digital Curation Conference: "Moving to Multi-Scale > Science," London, 2-4 December > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > On 9 Sep 2009, at 09:59, Barbara Sierman wrote: > > >> Yes I agree with Helen and with the general remarks that the >> repository has some responsibility when allowing an auditor on >> their premises. David said CCSDS requires such a paragraph, well >> that's ok but it should be brief. I assume other standards will >> have similar paragraphs? >> >> >> >> Kind regards, >> >> >> Barbara Sierman >> Digital Preservation Manager / Research and Development >> >> Koninklijke Bibliotheek >> PO Box 90407 >> 2509 LK Den Haag, The Netherlands >> >> +31 70 3140109 >> barbara.sierman@kb.nl >> >> www.kb.nl >> >> Van: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac- >> bounces@mailman.ccsds.org] Namens Helen Tibbo >> Verzonden: woensdag 9 september 2009 0:27 >> Aan: 'MOIMS-Repository Audit and Certification Working Group' >> Onderwerp: RE: [Moims-rac] Replacement text in Annex A >> >> >> >> Well this appears to be a CYA annex. If the language is cleaned up >> a bit it seems OK. Of greater concern, outside this Mission >> Impossible scenario, is the poor auditor and the effect of poor >> advice resulting in data loss. I think this too is beyond the >> standard. We cannot predict how people will use the standard. Some >> mechanics are good, some not so good; some surgeons using a >> standardized technique are fabulously successful, others have a >> poor track record. That does not mean the standard of care or the >> surgical technique are poor, just the application. -Helen >> >> >> >> Dr. Helen R. Tibbo >> >> School of Information and Library Science >> >> 201 Manning Hall CB#3360 >> >> University of North Carolina at Chapel Hill Chapel Hill, NC 27599-3360 >> >> Tel: 919-962-8063 >> >> Fax: 919-962-8071 >> >> Email: tibbo@email.unc.edu >> >> >> >> >> >> From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac- >> bounces@mailman.ccsds.org] On Behalf Of bambacher@verizon.net >> Sent: Tuesday, September 08, 2009 5:52 PM >> To: moims-rac@mailman.ccsds.org >> Subject: Re: [Moims-rac] Replacement text in Annex A >> >> >> >> David, >> I find the substitute very poorly worded. It is not acceptable >> from that perspective alone. >> >> I do not even understand the Introduction - its purpose or what it >> is saying. It also seems to be overkill. We certainly can >> adddress these issues in the auditor's handbook. We already >> addressed the possibility of keeping certain audit information >> restricted to avoid revealing such weaknesses. And anyone who >> contracts with one person/team to conduct an audit and allows >> someone else to perform the audit, without an acceptable >> explanation, deserves to be fooled. >> >> Once I understand the aims of each section I am willing to help >> rewrite it. >> >> When will we start working on the handbook? >> >> On Sep 8, 2009, Giaretta, David (STFC,RAL,SSTD) >> wrote: >> >> Dear WG members >> >> I've had some discussions with the CCSDS editor and security >> consultant >> about Annex - the Security annex - specifically what security concerns >> arise if one uses the document. The following replacement text seems >> acceptable. So no change to the metrics but rather just replacement of >> Annex A. >> >> Please let me know as soon as possible if you have any problems with >> this. >> >> ..David >> >> ----------------- New text for Annex A --------- >> >> SECURITY >> 1 INTRODUCTION >> The use of the Audit and Certification standard has several potential >> areas of security concern. >> One security concern is the possibility that the repository is fooled >> into undergoing an archive by someone unqualified or even malicious. >> Another concern involves the possible release of confidential >> information which is collected as evidence by the auditor. >> >> 2 SECURITY CONCERNS WITH RESPECT TO THE CCSDS DOCUMENT >> The repository may ask someone to perform an audit using this >> standard. >> There is a possibility that the person contacted is not in fact the >> person that the repository believes. Alternatively the correct person >> may be contacted but in fact another, possibly malicious, person may >> turn up to perform the audit. >> In the process of collecting evidence for the various metrics the >> auditor may collect information which is confidential or sensitive, >> for >> example details of security weaknesses. >> There is a danger that such information may fall into the wrong hands >> and expose the repository to increased risk. Alternatively in the >> process of collecting evidence the repository system may be damaged. >> While these are all valid security concerns, they fall outside the >> purview of this standard, which applies only to the metrics which an >> auditor should use for auditing a repository. >> >> 3 POTENTIAL THREATS AND ATTACK SCENARIOS >> Impersonation of an auditor and/or release of confidential information >> could both result in exposing the repository and its holdings to >> increased risk and loss of reputation of the repository. >> >> 4 CONSEQUENCES OF NOT APPLYING SECURITY TO THE TECHNOLOGY >> While these security issues are of concern, they are out of scope with >> respect to this document. This document aims to provide the basis >> for an >> audit and certification process for assessing the trustworthiness of >> digital repositories. Providing protection against false auditors must >> rely on the repository's identification and authorisation systems. >> Protection against loss of confidential information in the >> possession of >> the auditor must be provided by the security system of that auditor >> and >> the method of transmission of information which is agreed between the >> repository and auditor. Protection against damage to the repository or >> its holdings during an audit must rely on the security and safety >> systems of the repository. >> -- >> Scanned by iCritical. >> >> _______________________________________________ >> Moims-rac mailing list >> Moims-rac@mailman.ccsds.org >> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac >> >> _______________________________________________ >> Moims-rac mailing list >> Moims-rac@mailman.ccsds.org >> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac >> > > > _______________________________________________ > Moims-rac mailing list > Moims-rac@mailman.ccsds.org > http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac > From tibbo at email.unc.edu Wed Sep 9 12:28:00 2009 From: tibbo at email.unc.edu (Helen Tibbo) Date: Wed Sep 9 11:59:08 2009 Subject: [Moims-rac] address of Reagan Moore In-Reply-To: <1.3.200909091606.81483@mclink.it> References: <1.3.200909091606.81483@mclink.it> Message-ID: <006801ca316a$7f580610$7e081230$@unc.edu> Dear Mariella, Sure! Hope you are doing well. His address is rwmoore.email.unc.edu Dr. Helen R. Tibbo School of Information and Library Science 201 Manning Hall CB#3360 University of North Carolina at Chapel Hill Chapel Hill, NC 27599-3360 Tel: 919-962-8063 Fax: 919-962-8071 Email: tibbo@email.unc.edu -----Original Message----- From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Maria Guercio Sent: Wednesday, September 09, 2009 10:06 AM To: moims-rac@mailman.ccsds.org Subject: [Moims-rac] address of Reagan Moore Dear Helen I need the email address of Reagan for a payment related to Caspar. I do not know if the old one is still working Can you help me? Mariella _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac From tibbo at email.unc.edu Wed Sep 9 12:28:31 2009 From: tibbo at email.unc.edu (Helen Tibbo) Date: Wed Sep 9 11:59:39 2009 Subject: [Moims-rac] Replacement text in Annex A In-Reply-To: <4AA7D539.9020304@ciesin.columbia.edu> References: <1612833087.1239597.1252446705593.JavaMail.root@vms124.mailsrvcs.net><010801ca30d3$72d22d90$587688b0$@unc.edu><68C22185DB90CA41A5ACBD8E834C5ECD05C05E00@goofy.wpakb.kb.nl> <4AA7D539.9020304@ciesin.columbia.edu> Message-ID: <006b01ca316a$91e30870$b5a91950$@unc.edu> I second Bob's recommendation. -Helen Dr. Helen R. Tibbo School of Information and Library Science 201 Manning Hall CB#3360 University of North Carolina at Chapel Hill Chapel Hill, NC 27599-3360 Tel: 919-962-8063 Fax: 919-962-8071 Email: tibbo@email.unc.edu -----Original Message----- From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Robert R. Downs Sent: Wednesday, September 09, 2009 12:18 PM To: MOIMS-Repository Audit and Certification Working Group Subject: Re: [Moims-rac] Replacement text in Annex A To move forward, I suggest that we include the proposed statements for Annex A, revising the text to include the phrasing changes that have been offered for improvement. Thanks, Bob Giaretta, David (STFC,RAL,SSTD) wrote: > OAIS benefits from a "grandfather" clause. > > The CCSDS Pub Manual is being updated even now. > > > -----Original Message----- > From: moims-rac-bounces@mailman.ccsds.org > [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Chris > Rusbridge > Sent: 09 September 2009 17:01 > To: MOIMS-Repository Audit and Certification Working Group > Subject: Re: [Moims-rac] Replacement text in Annex A > > This certainly does appear to be a bit of bureaucratic nonsense, and > I agree that any statement should be briefer; something to the effect > that an audit may require disclosure of confidential information, and > agreements must be in place to protect that information. The "man in > the middle" attack scenario is far-fetched and can be discounted. > > I note that the OAIS revision candidate document (Pink book) that I > have contains no such annex or statement. And the CCSDS Publications > manual (2005 edition) does not contain the word "security"! > > -- > Chris Rusbridge > Director, Digital Curation Centre > Email: c.rusbridge@ed.ac.uk Phone 0131 6513823 > University of Edinburgh > Appleton Tower, Crichton St, Edinburgh EH8 9LE > > 5th International Digital Curation Conference: "Moving to Multi-Scale > Science," London, 2-4 December > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > On 9 Sep 2009, at 09:59, Barbara Sierman wrote: > > >> Yes I agree with Helen and with the general remarks that the >> repository has some responsibility when allowing an auditor on >> their premises. David said CCSDS requires such a paragraph, well >> that's ok but it should be brief. I assume other standards will >> have similar paragraphs? >> >> >> >> Kind regards, >> >> >> Barbara Sierman >> Digital Preservation Manager / Research and Development >> >> Koninklijke Bibliotheek >> PO Box 90407 >> 2509 LK Den Haag, The Netherlands >> >> +31 70 3140109 >> barbara.sierman@kb.nl >> >> www.kb.nl >> >> Van: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac- >> bounces@mailman.ccsds.org] Namens Helen Tibbo >> Verzonden: woensdag 9 september 2009 0:27 >> Aan: 'MOIMS-Repository Audit and Certification Working Group' >> Onderwerp: RE: [Moims-rac] Replacement text in Annex A >> >> >> >> Well this appears to be a CYA annex. If the language is cleaned up >> a bit it seems OK. Of greater concern, outside this Mission >> Impossible scenario, is the poor auditor and the effect of poor >> advice resulting in data loss. I think this too is beyond the >> standard. We cannot predict how people will use the standard. Some >> mechanics are good, some not so good; some surgeons using a >> standardized technique are fabulously successful, others have a >> poor track record. That does not mean the standard of care or the >> surgical technique are poor, just the application. -Helen >> >> >> >> Dr. Helen R. Tibbo >> >> School of Information and Library Science >> >> 201 Manning Hall CB#3360 >> >> University of North Carolina at Chapel Hill Chapel Hill, NC 27599-3360 >> >> Tel: 919-962-8063 >> >> Fax: 919-962-8071 >> >> Email: tibbo@email.unc.edu >> >> >> >> >> >> From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac- >> bounces@mailman.ccsds.org] On Behalf Of bambacher@verizon.net >> Sent: Tuesday, September 08, 2009 5:52 PM >> To: moims-rac@mailman.ccsds.org >> Subject: Re: [Moims-rac] Replacement text in Annex A >> >> >> >> David, >> I find the substitute very poorly worded. It is not acceptable >> from that perspective alone. >> >> I do not even understand the Introduction - its purpose or what it >> is saying. It also seems to be overkill. We certainly can >> adddress these issues in the auditor's handbook. We already >> addressed the possibility of keeping certain audit information >> restricted to avoid revealing such weaknesses. And anyone who >> contracts with one person/team to conduct an audit and allows >> someone else to perform the audit, without an acceptable >> explanation, deserves to be fooled. >> >> Once I understand the aims of each section I am willing to help >> rewrite it. >> >> When will we start working on the handbook? >> >> On Sep 8, 2009, Giaretta, David (STFC,RAL,SSTD) >> wrote: >> >> Dear WG members >> >> I've had some discussions with the CCSDS editor and security >> consultant >> about Annex - the Security annex - specifically what security concerns >> arise if one uses the document. The following replacement text seems >> acceptable. So no change to the metrics but rather just replacement of >> Annex A. >> >> Please let me know as soon as possible if you have any problems with >> this. >> >> ..David >> >> ----------------- New text for Annex A --------- >> >> SECURITY >> 1 INTRODUCTION >> The use of the Audit and Certification standard has several potential >> areas of security concern. >> One security concern is the possibility that the repository is fooled >> into undergoing an archive by someone unqualified or even malicious. >> Another concern involves the possible release of confidential >> information which is collected as evidence by the auditor. >> >> 2 SECURITY CONCERNS WITH RESPECT TO THE CCSDS DOCUMENT >> The repository may ask someone to perform an audit using this >> standard. >> There is a possibility that the person contacted is not in fact the >> person that the repository believes. Alternatively the correct person >> may be contacted but in fact another, possibly malicious, person may >> turn up to perform the audit. >> In the process of collecting evidence for the various metrics the >> auditor may collect information which is confidential or sensitive, >> for >> example details of security weaknesses. >> There is a danger that such information may fall into the wrong hands >> and expose the repository to increased risk. Alternatively in the >> process of collecting evidence the repository system may be damaged. >> While these are all valid security concerns, they fall outside the >> purview of this standard, which applies only to the metrics which an >> auditor should use for auditing a repository. >> >> 3 POTENTIAL THREATS AND ATTACK SCENARIOS >> Impersonation of an auditor and/or release of confidential information >> could both result in exposing the repository and its holdings to >> increased risk and loss of reputation of the repository. >> >> 4 CONSEQUENCES OF NOT APPLYING SECURITY TO THE TECHNOLOGY >> While these security issues are of concern, they are out of scope with >> respect to this document. This document aims to provide the basis >> for an >> audit and certification process for assessing the trustworthiness of >> digital repositories. Providing protection against false auditors must >> rely on the repository's identification and authorisation systems. >> Protection against loss of confidential information in the >> possession of >> the auditor must be provided by the security system of that auditor >> and >> the method of transmission of information which is agreed between the >> repository and auditor. Protection against damage to the repository or >> its holdings during an audit must rely on the security and safety >> systems of the repository. >> -- >> Scanned by iCritical. >> >> _______________________________________________ >> Moims-rac mailing list >> Moims-rac@mailman.ccsds.org >> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac >> >> _______________________________________________ >> Moims-rac mailing list >> Moims-rac@mailman.ccsds.org >> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac >> > > > _______________________________________________ > Moims-rac mailing list > Moims-rac@mailman.ccsds.org > http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac > _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac From FerranteR at si.edu Wed Sep 9 14:30:58 2009 From: FerranteR at si.edu (Ferrante, Riccardo) Date: Wed Sep 9 14:02:16 2009 Subject: [Moims-rac] Replacement text in Annex A Message-ID: Agreed. Ricc Riccardo Ferrante Electronic Records Program Director Smithsonian Institution Archives E - FerranteR@si.edu P - 202-633-5906 F.- 202-633-5928 C - 202-341-4658 ----- Original Message ----- From: moims-rac-bounces@mailman.ccsds.org To: 'MOIMS-Repository Audit and Certification Working Group' Sent: Wed Sep 09 12:28:31 2009 Subject: RE: [Moims-rac] Replacement text in Annex A I second Bob's recommendation. -Helen Dr. Helen R. Tibbo School of Information and Library Science 201 Manning Hall CB#3360 University of North Carolina at Chapel Hill Chapel Hill, NC 27599-3360 Tel: 919-962-8063 Fax: 919-962-8071 Email: tibbo@email.unc.edu -----Original Message----- From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Robert R. Downs Sent: Wednesday, September 09, 2009 12:18 PM To: MOIMS-Repository Audit and Certification Working Group Subject: Re: [Moims-rac] Replacement text in Annex A To move forward, I suggest that we include the proposed statements for Annex A, revising the text to include the phrasing changes that have been offered for improvement. Thanks, Bob Giaretta, David (STFC,RAL,SSTD) wrote: > OAIS benefits from a "grandfather" clause. > > The CCSDS Pub Manual is being updated even now. > > > -----Original Message----- > From: moims-rac-bounces@mailman.ccsds.org > [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Chris > Rusbridge > Sent: 09 September 2009 17:01 > To: MOIMS-Repository Audit and Certification Working Group > Subject: Re: [Moims-rac] Replacement text in Annex A > > This certainly does appear to be a bit of bureaucratic nonsense, and > I agree that any statement should be briefer; something to the effect > that an audit may require disclosure of confidential information, and > agreements must be in place to protect that information. The "man in > the middle" attack scenario is far-fetched and can be discounted. > > I note that the OAIS revision candidate document (Pink book) that I > have contains no such annex or statement. And the CCSDS Publications > manual (2005 edition) does not contain the word "security"! > > -- > Chris Rusbridge > Director, Digital Curation Centre > Email: c.rusbridge@ed.ac.uk Phone 0131 6513823 > University of Edinburgh > Appleton Tower, Crichton St, Edinburgh EH8 9LE > > 5th International Digital Curation Conference: "Moving to Multi-Scale > Science," London, 2-4 December > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > On 9 Sep 2009, at 09:59, Barbara Sierman wrote: > > >> Yes I agree with Helen and with the general remarks that the >> repository has some responsibility when allowing an auditor on >> their premises. David said CCSDS requires such a paragraph, well >> that's ok but it should be brief. I assume other standards will >> have similar paragraphs? >> >> >> >> Kind regards, >> >> >> Barbara Sierman >> Digital Preservation Manager / Research and Development >> >> Koninklijke Bibliotheek >> PO Box 90407 >> 2509 LK Den Haag, The Netherlands >> >> +31 70 3140109 >> barbara.sierman@kb.nl >> >> www.kb.nl >> >> Van: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac- >> bounces@mailman.ccsds.org] Namens Helen Tibbo >> Verzonden: woensdag 9 september 2009 0:27 >> Aan: 'MOIMS-Repository Audit and Certification Working Group' >> Onderwerp: RE: [Moims-rac] Replacement text in Annex A >> >> >> >> Well this appears to be a CYA annex. If the language is cleaned up >> a bit it seems OK. Of greater concern, outside this Mission >> Impossible scenario, is the poor auditor and the effect of poor >> advice resulting in data loss. I think this too is beyond the >> standard. We cannot predict how people will use the standard. Some >> mechanics are good, some not so good; some surgeons using a >> standardized technique are fabulously successful, others have a >> poor track record. That does not mean the standard of care or the >> surgical technique are poor, just the application. -Helen >> >> >> >> Dr. Helen R. Tibbo >> >> School of Information and Library Science >> >> 201 Manning Hall CB#3360 >> >> University of North Carolina at Chapel Hill Chapel Hill, NC 27599-3360 >> >> Tel: 919-962-8063 >> >> Fax: 919-962-8071 >> >> Email: tibbo@email.unc.edu >> >> >> >> >> >> From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac- >> bounces@mailman.ccsds.org] On Behalf Of bambacher@verizon.net >> Sent: Tuesday, September 08, 2009 5:52 PM >> To: moims-rac@mailman.ccsds.org >> Subject: Re: [Moims-rac] Replacement text in Annex A >> >> >> >> David, >> I find the substitute very poorly worded. It is not acceptable >> from that perspective alone. >> >> I do not even understand the Introduction - its purpose or what it >> is saying. It also seems to be overkill. We certainly can >> adddress these issues in the auditor's handbook. We already >> addressed the possibility of keeping certain audit information >> restricted to avoid revealing such weaknesses. And anyone who >> contracts with one person/team to conduct an audit and allows >> someone else to perform the audit, without an acceptable >> explanation, deserves to be fooled. >> >> Once I understand the aims of each section I am willing to help >> rewrite it. >> >> When will we start working on the handbook? >> >> On Sep 8, 2009, Giaretta, David (STFC,RAL,SSTD) >> wrote: >> >> Dear WG members >> >> I've had some discussions with the CCSDS editor and security >> consultant >> about Annex - the Security annex - specifically what security concerns >> arise if one uses the document. The following replacement text seems >> acceptable. So no change to the metrics but rather just replacement of >> Annex A. >> >> Please let me know as soon as possible if you have any problems with >> this. >> >> ..David >> >> ----------------- New text for Annex A --------- >> >> SECURITY >> 1 INTRODUCTION >> The use of the Audit and Certification standard has several potential >> areas of security concern. >> One security concern is the possibility that the repository is fooled >> into undergoing an archive by someone unqualified or even malicious. >> Another concern involves the possible release of confidential >> information which is collected as evidence by the auditor. >> >> 2 SECURITY CONCERNS WITH RESPECT TO THE CCSDS DOCUMENT >> The repository may ask someone to perform an audit using this >> standard. >> There is a possibility that the person contacted is not in fact the >> person that the repository believes. Alternatively the correct person >> may be contacted but in fact another, possibly malicious, person may >> turn up to perform the audit. >> In the process of collecting evidence for the various metrics the >> auditor may collect information which is confidential or sensitive, >> for >> example details of security weaknesses. >> There is a danger that such information may fall into the wrong hands >> and expose the repository to increased risk. Alternatively in the >> process of collecting evidence the repository system may be damaged. >> While these are all valid security concerns, they fall outside the >> purview of this standard, which applies only to the metrics which an >> auditor should use for auditing a repository. >> >> 3 POTENTIAL THREATS AND ATTACK SCENARIOS >> Impersonation of an auditor and/or release of confidential information >> could both result in exposing the repository and its holdings to >> increased risk and loss of reputation of the repository. >> >> 4 CONSEQUENCES OF NOT APPLYING SECURITY TO THE TECHNOLOGY >> While these security issues are of concern, they are out of scope with >> respect to this document. This document aims to provide the basis >> for an >> audit and certification process for assessing the trustworthiness of >> digital repositories. Providing protection against false auditors must >> rely on the repository's identification and authorisation systems. >> Protection against loss of confidential information in the >> possession of >> the auditor must be provided by the security system of that auditor >> and >> the method of transmission of information which is agreed between the >> repository and auditor. Protection against damage to the repository or >> its holdings during an audit must rely on the security and safety >> systems of the repository. >> -- >> Scanned by iCritical. >> >> _______________________________________________ >> Moims-rac mailing list >> Moims-rac@mailman.ccsds.org >> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac >> >> _______________________________________________ >> Moims-rac mailing list >> Moims-rac@mailman.ccsds.org >> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac >> > > > _______________________________________________ > Moims-rac mailing list > Moims-rac@mailman.ccsds.org > http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac > _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac From simon.lambert at stfc.ac.uk Wed Sep 9 17:23:30 2009 From: simon.lambert at stfc.ac.uk (Lambert, Simon (STFC,RAL,ESC)) Date: Wed Sep 9 16:54:51 2009 Subject: [Moims-rac] Progressing the "Requirements for Bodies ..." document Message-ID: <677CE4DD24B12C4B9FA138534E29FB1D04EAAB71@exchange11.fed.cclrc.ac.uk> I've put a new version of the "Requirements for Bodies ..." document on the wiki at http://wiki.digitalrepositoryauditandcertification.org/bin/view/Main/ReqtsForAuditors. This identifies areas that might need further revision to suit the Trusted Digital Repositories context. I have also extracted those particular areas and put them on a separate wiki page at http://wiki.digitalrepositoryauditandcertification.org/bin/view/Main/AuditorGuidelinesIssues for ease of reference and editing. I hope this will enable us to progress with this document in a convenient way. Simon Lambert -- Scanned by iCritical. From Barbara.Sierman at KB.nl Wed Sep 16 09:27:40 2009 From: Barbara.Sierman at KB.nl (Barbara Sierman) Date: Wed Sep 16 08:58:57 2009 Subject: [Moims-rac] CCSDS meeting in ESTEC/ESA, Noordwijk, The Netherlands In-Reply-To: References: Message-ID: <68C22185DB90CA41A5ACBD8E834C5ECD05C52503@goofy.wpakb.kb.nl> Dear David, I will be able to attend a meeting on Wednesday 27th. See you next Monday! Kind regards, Barbara Sierman Digital Preservation Manager / Research and Development Koninklijke Bibliotheek PO Box 90407 2509 LK Den Haag, The Netherlands +31 70 3140109 barbara.sierman@kb.nl www.kb.nl > -----Oorspronkelijk bericht----- > Van: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac- > bounces@mailman.ccsds.org] Namens Giaretta, David (STFC,RAL,SSTD) > Verzonden: woensdag 9 september 2009 11:34 > Aan: moims-rac@mailman.ccsds.org > Onderwerp: [Moims-rac] CCSDS meeting in ESTEC/ESA, Noordwijk, The Netherlands > > The CCSDS meetings are going to be held in ESA/ESTEC, Noordwijk in the > Netherlands in the week of 26-30 October. > > Will any of the WG be able to travel there? I guess this really is a > question for those based in and around the Netherlands, since there is > no funding. I was thinking that it might be valuable for those who can > make it to get together on Wednesday 27th for a general discussion about > strategy in the morning and then hold a telecom with the rest of the > group in the afternoon. > > Please let me know ASAP if you plan to attend, so I can book an > appropriate room. > > Regards > > ..David > -- > Scanned by iCritical. > > _______________________________________________ > Moims-rac mailing list > Moims-rac@mailman.ccsds.org > http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac From david.giaretta at stfc.ac.uk Tue Sep 22 17:41:35 2009 From: david.giaretta at stfc.ac.uk (Giaretta, David (STFC,RAL,SSTD)) Date: Tue Sep 22 17:12:34 2009 Subject: [Moims-rac] RAC virtual meetings Message-ID: <017001ca3bcd$5fd3e2a1$2f8510ac@fed.cclrc.ac.uk> Dear all As Simon said in his last email we need to finish the Requirements for Bodies... Although this is short notice, I hope some people may be available for a megameeting tomorrow at the usual time to discuss the document. Regards David -- Scanned by iCritical. From waltz at crl.edu Tue Sep 22 17:42:58 2009 From: waltz at crl.edu (Marie Waltz) Date: Tue Sep 22 17:18:14 2009 Subject: [Moims-rac] RAC virtual meetings In-Reply-To: <017001ca3bcd$5fd3e2a1$2f8510ac@fed.cclrc.ac.uk> References: <017001ca3bcd$5fd3e2a1$2f8510ac@fed.cclrc.ac.uk> Message-ID: <9E612AEEF6ADB74A8690EC3F91B79C84017BB362@crlexchange.LAN_DOMAIN.EDU> Hi David- If you mean the usual time of 3:30 GMT that is fine with me. Marie -----Original Message----- From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Giaretta, David (STFC,RAL,SSTD) Sent: Tuesday, September 22, 2009 4:42 PM To: MOIMS-RAC Subject: [Moims-rac] RAC virtual meetings Dear all As Simon said in his last email we need to finish the Requirements for Bodies... Although this is short notice, I hope some people may be available for a megameeting tomorrow at the usual time to discuss the document. Regards David -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac From david.giaretta at stfc.ac.uk Tue Sep 22 17:48:57 2009 From: david.giaretta at stfc.ac.uk (Giaretta, David (STFC,RAL,SSTD)) Date: Tue Sep 22 17:20:53 2009 Subject: [Moims-rac] RAC virtual meetings In-Reply-To: <9E612AEEF6ADB74A8690EC3F91B79C84017BB362@crlexchange.LAN_DOMAIN.EDU> References: <017001ca3bcd$5fd3e2a1$2f8510ac@fed.cclrc.ac.uk> <9E612AEEF6ADB74A8690EC3F91B79C84017BB362@crlexchange.LAN_DOMAIN.EDU> Message-ID: Yes, that's right, 3:30 UK time ..David -----Original Message----- From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Marie Waltz Sent: 22 September 2009 22:43 To: MOIMS-Repository Audit and Certification Working Group Subject: RE: [Moims-rac] RAC virtual meetings Hi David- If you mean the usual time of 3:30 GMT that is fine with me. Marie -----Original Message----- From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Giaretta, David (STFC,RAL,SSTD) Sent: Tuesday, September 22, 2009 4:42 PM To: MOIMS-RAC Subject: [Moims-rac] RAC virtual meetings Dear all As Simon said in his last email we need to finish the Requirements for Bodies... Although this is short notice, I hope some people may be available for a megameeting tomorrow at the usual time to discuss the document. Regards David -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -- Scanned by iCritical. From bambacher at verizon.net Wed Sep 23 09:32:55 2009 From: bambacher at verizon.net (bambacher@verizon.net) Date: Wed Sep 23 09:04:42 2009 Subject: [Moims-rac] RAC virtual meetings Message-ID: <1288738465.191510.1253712775387.JavaMail.root@vms228.mailsrvcs.net> An HTML attachment was scrubbed... URL: http://mailman.ccsds.org/pipermail/moims-rac/attachments/20090923/ea4feb9c/attachment.htm From FerranteR at si.edu Wed Sep 23 09:35:13 2009 From: FerranteR at si.edu (Ferrante, Riccardo) Date: Wed Sep 23 09:06:42 2009 Subject: [Moims-rac] RAC virtual meetings Message-ID: <8E16D65E47BAA64B8D4AE6C1BD771CE7010DAB0D@SI-MSEV04.US.SINET.SI.EDU> My apologies. I have 2 concurrent conflicts and am still working on cloning myself. Best, Ricc Riccardo Ferrante Electronic Records Program Director Smithsonian Institution Archives E - FerranteR@si.edu P - 202-633-5906 F.- 202-633-5928 C - 202-341-4658 ________________________________ From: moims-rac-bounces@mailman.ccsds.org To: moims-rac@mailman.ccsds.org Sent: Wed Sep 23 09:32:55 2009 Subject: Re: RE: [Moims-rac] RAC virtual meetings David, It is the appointed time and no one is logged on. On Sep 22, 2009, Giaretta, David (STFC,RAL,SSTD) wrote: Yes, that's right, 3:30 UK time ..David -----Original Message----- From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Marie Waltz Sent: 22 September 2009 22:43 To: MOIMS-Repository Audit and Certification Working Group Subject: RE: [Moims-rac] RAC virtual meetings Hi David- If you mean the usual time of 3:30 GMT that is fine with me. Marie -----Original Message----- From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Giaretta, David (STFC,RAL,SSTD) Sent: Tuesday, September 22, 2009 4:42 PM To: MOIMS-RAC Subject: [Moims-rac] RAC virtual meetings Dear all As Simon said in his last email we need to finish the Requirements for Bodies... Although this is short notice, I hope some people may be available for a megameeting tomorrow at the usual time to discuss the document. Regards David -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ccsds.org/pipermail/moims-rac/attachments/20090923/027b1986/attachment.htm From david.giaretta at stfc.ac.uk Wed Sep 23 09:35:59 2009 From: david.giaretta at stfc.ac.uk (Giaretta, David (STFC,RAL,SSTD)) Date: Wed Sep 23 09:12:54 2009 Subject: [Moims-rac] RAC virtual meetings In-Reply-To: <1288738465.191510.1253712775387.JavaMail.root@vms228.mailsrvcs.net> References: <1288738465.191510.1253712775387.JavaMail.root@vms228.mailsrvcs.net> Message-ID: I thought it was in 1 hour?s time ? I?ll join now. ..David From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of bambacher@verizon.net Sent: 23 September 2009 14:33 To: moims-rac@mailman.ccsds.org Subject: Re: RE: [Moims-rac] RAC virtual meetings David, It is the appointed time and no one is logged on. On Sep 22, 2009, Giaretta, David (STFC,RAL,SSTD) wrote: Yes, that's right, 3:30 UK time ..David -----Original Message----- From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Marie Waltz Sent: 22 September 2009 22:43 To: MOIMS-Repository Audit and Certification Working Group Subject: RE: [Moims-rac] RAC virtual meetings Hi David- If you mean the usual time of 3:30 GMT that is fine with me. Marie -----Original Message----- From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Giaretta, David (STFC,RAL,SSTD) Sent: Tuesday, September 22, 2009 4:42 PM To: MOIMS-RAC Subject: [Moims-rac] RAC virtual meetings Dear all As Simon said in his last email we need to finish the Requirements for Bodies... Although this is short notice, I hope some people may be available for a megameeting tomorrow at the usual time to discuss the document. Regards David -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ccsds.org/pipermail/moims-rac/attachments/20090923/12499db4/attachment-0001.html From mark.conrad at nara.gov Wed Sep 23 09:42:34 2009 From: mark.conrad at nara.gov (Mark Conrad) Date: Wed Sep 23 09:14:15 2009 Subject: [Moims-rac] RAC virtual meetings Message-ID: I thought it was 10:30 EDT. Are we supposed to be online now? Mark >>> bambacher@verizon.net 9/23/2009 9:32 AM >>> David, It is the appointed time and no one is logged on. On Sep 22, 2009, Giaretta, David (STFC,RAL,SSTD) wrote: Yes, that's right, 3:30 UK time ..David -----Original Message----- From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Marie Waltz Sent: 22 September 2009 22:43 To: MOIMS-Repository Audit and Certification Working Group Subject: RE: [Moims-rac] RAC virtual meetings Hi David- If you mean the usual time of 3:30 GMT that is fine with me. Marie -----Original Message----- From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Giaretta, David (STFC,RAL,SSTD) Sent: Tuesday, September 22, 2009 4:42 PM To: MOIMS-RAC Subject: [Moims-rac] RAC virtual meetings Dear all As Simon said in his last email we need to finish the Requirements for Bodies... Although this is short notice, I hope some people may be available for a megameeting tomorrow at the usual time to discuss the document. Regards David -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ccsds.org/pipermail/moims-rac/attachments/20090923/f4ab5158/attachment.htm From rdowns at ciesin.columbia.edu Wed Sep 23 09:50:33 2009 From: rdowns at ciesin.columbia.edu (Robert R. Downs) Date: Wed Sep 23 09:21:39 2009 Subject: [Moims-rac] RAC virtual meetings In-Reply-To: <8E16D65E47BAA64B8D4AE6C1BD771CE7010DAB0D@SI-MSEV04.US.SINET.SI.EDU> References: <8E16D65E47BAA64B8D4AE6C1BD771CE7010DAB0D@SI-MSEV04.US.SINET.SI.EDU> Message-ID: <4ABA27A9.6000908@ciesin.columbia.edu> David and all, I also am sorry that I will not be able to attend today, due to conflicts. Thanks, Bob Ferrante, Riccardo wrote: > > My apologies. I have 2 concurrent conflicts and am still working on > cloning myself. > > Best, > > Ricc > > Riccardo Ferrante > Electronic Records Program Director > Smithsonian Institution Archives > E - FerranteR@si.edu > P - 202-633-5906 > F.- 202-633-5928 > C - 202-341-4658 > > ------------------------------------------------------------------------ > *From*: moims-rac-bounces@mailman.ccsds.org > > *To*: moims-rac@mailman.ccsds.org > *Sent*: Wed Sep 23 09:32:55 2009 > *Subject*: Re: RE: [Moims-rac] RAC virtual meetings > David, > It is the appointed time and no one is logged on. > > On Sep 22, 2009, *Giaretta, David (STFC,RAL,SSTD)* > wrote: > > Yes, that's right, 3:30 UK time > > ..David > > -----Original Message----- > From: moims-rac-bounces@mailman.ccsds.org > > [mailto:moims-rac-bounces@mailman.ccsds.org > ] On Behalf Of Marie Waltz > Sent: 22 September 2009 22:43 > To: MOIMS-Repository Audit and Certification Working Group > Subject: RE: [Moims-rac] RAC virtual meetings > > Hi David- > > If you mean the usual time of 3:30 GMT that is fine with me. > > Marie > > -----Original Message----- > From: moims-rac-bounces@mailman.ccsds.org > > [mailto:moims-rac-bounces@mailman.ccsds.org > ] On Behalf Of Giaretta, > David (STFC,RAL,SSTD) > Sent: Tuesday, September 22, 2009 4:42 PM > To: MOIMS-RAC > Subject: [Moims-rac] RAC virtual meetings > > Dear all > > As Simon said in his last email we need to finish the Requirements for > Bodies... > > Although this is short notice, I hope some people may be available > for a > megameeting tomorrow at the usual time to discuss the document. > > Regards > > David -- > Scanned by iCritical. > > _______________________________________________ > Moims-rac mailing list > Moims-rac@mailman.ccsds.org > http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac > > _______________________________________________ > Moims-rac mailing list > Moims-rac@mailman.ccsds.org > http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac > -- > Scanned by iCritical. > > _______________________________________________ > Moims-rac mailing list > Moims-rac@mailman.ccsds.org > http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac > > ------------------------------------------------------------------------ > > _______________________________________________ > Moims-rac mailing list > Moims-rac@mailman.ccsds.org > http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac > From bambacher at verizon.net Thu Sep 24 10:33:43 2009 From: bambacher at verizon.net (bambacher@verizon.net) Date: Thu Sep 24 10:05:30 2009 Subject: [Moims-rac] Virtual megameetings to resume Message-ID: <662517474.129293.1253802823672.JavaMail.root@vms227.mailsrvcs.net> An HTML attachment was scrubbed... URL: http://mailman.ccsds.org/pipermail/moims-rac/attachments/20090924/acb5510a/attachment.html From david.giaretta at stfc.ac.uk Wed Sep 30 03:20:12 2009 From: david.giaretta at stfc.ac.uk (Giaretta, David (STFC,RAL,SSTD)) Date: Wed Sep 30 02:51:58 2009 Subject: [Moims-rac] Choice of day Message-ID: Dear all Looking at the matrix for choice of time/day http://wiki.digitalrepositoryauditandcertification.org/bin/view/Main/Day ChoiceMatrix it looks as if Monday is a winner and 15:30 (or 16:00 if necessary) UK time the choice of time. There is a MegaMeeting scheduled for today so I suggest we touch base at that and then move to a Monday routine. Any problem with that? Having said that I may have difficulties because of travel arrangements I may be late today and on Monday there is iPRES in San Francisco, although for the latter it would be 07:30 am local so that should be OK. Regards ..David -- Scanned by iCritical. From mark.conrad at nara.gov Wed Sep 30 10:09:38 2009 From: mark.conrad at nara.gov (Mark Conrad) Date: Wed Sep 30 09:41:46 2009 Subject: [Moims-rac] Choice of day Message-ID: What time is the MegaMeeting scheduled for today? I believe Bruce's e-mail said 10 EDT, but I thought we agreed to 10:30 am EDT. At this point there are three of us online. What time are people planning to come to the MegaMeeting? Mark Mark Conrad NARA Center for Advanced Systems and Technologies NHA The National Archives and Records Administration Erma Ora Byrd Conference and Learning Center Building 494 Second Floor 610 State Route 956 Rocket Center, WV 26726 Phone: 304-726-7820 Fax: 304-726-7802 Email: mark.conrad@nara.gov >>> david.giaretta@stfc.ac.uk 9/30/2009 3:20 AM >>> Dear all Looking at the matrix for choice of time/day http://wiki.digitalrepositoryauditandcertification.org/bin/view/Main/Day ChoiceMatrix it looks as if Monday is a winner and 15:30 (or 16:00 if necessary) UK time the choice of time. There is a MegaMeeting scheduled for today so I suggest we touch base at that and then move to a Monday routine. Any problem with that? Having said that I may have difficulties because of travel arrangements I may be late today and on Monday there is iPRES in San Francisco, although for the latter it would be 07:30 am local so that should be OK. Regards ..David -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ccsds.org/pipermail/moims-rac/attachments/20090930/02763977/attachment.htm From david.giaretta at stfc.ac.uk Wed Sep 30 10:18:08 2009 From: david.giaretta at stfc.ac.uk (Giaretta, David (STFC,RAL,SSTD)) Date: Wed Sep 30 09:49:15 2009 Subject: [Moims-rac] Choice of day Message-ID: <194d01ca41d8$b99652fb$2d8510ac@fed.cclrc.ac.uk> Dear all I'm afraid I almost certainly will not be in a position to take part in the MegaMeeting so please start without me. Simon tells me he is traveling so will not be there either. Apologies. See you on Monday. david -----Original Message----- From: Giaretta, David (STFC,RAL,SSTD) Sent: 30 September 2009 08:22 To: MOIMS-Repository Audit and Certification Working Group Subject: [Moims-rac] Choice of day Dear all Looking at the matrix for choice of time/day http://wiki.digitalrepositoryauditandcertification.org/bin/view/Main/Day ChoiceMatrix it looks as if Monday is a winner and 15:30 (or 16:00 if necessary) UK time the choice of time. There is a MegaMeeting scheduled for today so I suggest we touch base at that and then move to a Monday routine. Any problem with that? Having said that I may have difficulties because of travel arrangements I may be late today and on Monday there is iPRES in San Francisco, although for the latter it would be 07:30 am local so that should be OK. Regards ..David -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -- Scanned by iCritical. From david.giaretta at stfc.ac.uk Wed Sep 30 10:20:12 2009 From: david.giaretta at stfc.ac.uk (Giaretta, David (STFC,RAL,SSTD)) Date: Wed Sep 30 09:51:09 2009 Subject: [Moims-rac] Choice of day Message-ID: <194e01ca41d9$02cd20db$2d8510ac@fed.cclrc.ac.uk> Apologies my plane was delayed so I could not send a message earlier. David -----Original Message----- From: Mark Conrad Sent: 30 September 2009 15:16 To: MOIMS-Repository Audit and Certification Working Group ; david.giaretta@stfc.ac.uk Subject: Re: [Moims-rac] Choice of day What time is the MegaMeeting scheduled for today? I believe Bruce's e-mail said 10 EDT, but I thought we agreed to 10:30 am EDT. At this point there are three of us online. What time are people planning to come to the MegaMeeting? Mark Mark Conrad NARA Center for Advanced Systems and Technologies NHA The National Archives and Records Administration Erma Ora Byrd Conference and Learning Center Building 494 Second Floor 610 State Route 956 Rocket Center, WV 26726 Phone: 304-726-7820 Fax: 304-726-7802 Email: mark.conrad@nara.gov >>> david.giaretta@stfc.ac.uk 9/30/2009 3:20 AM >>> Dear all Looking at the matrix for choice of time/day http://wiki.digitalrepositoryauditandcertification.org/bin/view/Main/Day ChoiceMatrix it looks as if Monday is a winner and 15:30 (or 16:00 if necessary) UK time the choice of time. There is a MegaMeeting scheduled for today so I suggest we touch base at that and then move to a Monday routine. Any problem with that? Having said that I may have difficulties because of travel arrangements I may be late today and on Monday there is iPRES in San Francisco, although for the latter it would be 07:30 am local so that should be OK. Regards ..David -- Scanned by iCritical. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac -- Scanned by iCritical. From bambacher at verizon.net Wed Sep 30 10:19:52 2009 From: bambacher at verizon.net (bambacher@verizon.net) Date: Wed Sep 30 09:51:58 2009 Subject: [Moims-rac] Choice of day Message-ID: <2146966430.118.1254320392776.JavaMail.root@vms232.mailsrvcs.net> An HTML attachment was scrubbed... URL: http://mailman.ccsds.org/pipermail/moims-rac/attachments/20090930/166745fd/attachment.htm From mark.conrad at nara.gov Wed Sep 30 11:01:57 2009 From: mark.conrad at nara.gov (Mark Conrad) Date: Wed Sep 30 10:34:05 2009 Subject: [Moims-rac] Choice of day Message-ID: David, Simon, Here is the chat from today's meeting. We agreed to meet next Monday at 10:30 am EDT. Mark Mark Conrad >> (All): Good morning. RobertDowns >> (All): Good morning! Terry Longstreth >> (All): Good Morning; so, we're all West of Noon? Mark Conrad >> (All): Bruce's e-mail indicated that we would be meeting at 10 today, but I thought the agreed time was 10:30 EDT. Does anyone else have any info? RobertDowns >> (All): I saw Bruce's message, too, but perhaps others did not see it. Terry Longstreth >> (All): I think David was implying we use Bruce's time for today only. Mark Conrad >> (All): Agreed, but I think the time Bruce listed in his e-mail was not the time we agreed for today at the last meeting. Unfortunately the minutes from the last meeting have not been posted. I am sending out an e-mail message to the list to see when other people thought we are meeting today. Terry Longstreth >> (All): Fine. In the meantime, where do I find a copy of ISO ISO/IEC 17021:2006 to understand the references ? Mark Conrad >> (All): I have a copy on loan from David. He may be able to provide you with a copy. Mark Conrad >> (All): Should we try back at 10:30 and see if anyone shows up then? Terry Longstreth >> (All): OK Mark Conrad >> (All): See you later! RobertDowns >> (All): ok RobertDowns >> (All): Hi Bruce BruceAmbacher >> (All): Hi Robert. BruceAmbacher >> (All): When I find a few idle minutes I will send out the beginnings of a grant proposal - 3 years, experts meeting, promotion, training of auditors, conducting first audits, etc. IMLS has asked about this standard which might be interpreted as an interest in funding BruceAmbacher >> (All): As you can see above a few met at 10:00, disbanded and agreed to return at 10:30 RobertDowns >> (All): That's great Bruce. I look forward to seing it. RobertDowns >> (All): Yes, I was in the earlier group, too, but we decided to try again at 10:30 BruceAmbacher >> (All): I will try to get Helen to write it. She has an amazing track record. RobertDowns >> (All): That seems like a good approach BruceAmbacher >> (All): I still have your earlier input and will use that. JohnGarrett >> (All): Hi, I of course missed the changed time and thought it was 10:30 today BruceAmbacher >> (All): John, BruceAmbacher >> (All): everyone is messed up as to time and day RobertDowns >> (All): And next week we go back to Mondays? JohnGarrett >> (All): Yes I believe we go back to Mondays next week. I'm unsure what time. Mark Conrad >> (All): According to David's note, that was to be determined at today's meeting. JohnGarrett >> (All): For me, Monday morning is probably the best RobertDowns >> (All): Monday morning might be better for me, too. BruceAmbacher >> (All): Gentlemen, I am like an old plowhorse. Once you let me out of harness it is very difficult to get me back in and working. BruceAmbacher >> (All): Monday would be good for me. JohnGarrett >> (All): Fine with me, BruceAmbacher >> (All): I suggest 10:30 EDT RobertDowns >> (All): 10:30 EDT would work for me Mark Conrad >> (All): That will work for me - except for next Monday. JohnGarrett >> (All): Works for me. Plan for an hour meeting to start? RobertDowns >> (All): An hour seems fine. Mark Conrad >> (All): Ok. BruceAmbacher >> (All): What part(s) of the auditors' handbook do we want to focus on next Monday? JohnGarrett >> (All): Is plan for meeting to just march through the currentlyh identified areas to look at and decide to keep or throw out or add criteria? BruceAmbacher >> (All): John, Any hints as to when the standard will emerge from tech. editing? Mark Conrad >> (All): Bruce, You had comments on some sections already. Should we start with those? BruceAmbacher >> (All): OK. I just have to find them again. JohnGarrett >> (All): No, I thought it would be out by now. We of course had the problem with the security section that's now taken care of, but I thought that was the only hold up. JohnGarrett >> (All): I'm attending another video conference today regarding status of CCSDS WGs. Maybe I can get some info then if the CCSDS editor is on-line. BruceAmbacher >> (All): John, does anything happen between its emergence and when it circulates for international comment? BruceAmbacher >> (All): Welcome Helen, how is your semester going? Helen Tibbo >> (All): Hello - I am unprepared today - no headphone BruceAmbacher >> (All): Helen, interesting. You show up as having an active mike. JohnGarrett >> (All): I don't think so, but I don't know if the CCSDS and ISO reviews are simultaneous or in series. Regardless we'd like to get all the comments during the CCSDS review if possible so the ISO will just be a formality. Terry Longstreth >> (All): a new note from David.. he won't be on today. Nor Simon BruceAmbacher >> (All): Helen, we have agreed to "meet" on Monday starting at 10:30 EDT Mark Conrad >> (All): So are we doing anything else today or just regrouping and reconvening next Monday? BruceAmbacher >> (All): I vote for regrouping Monday. Mark, will you please capture text and submit to simon or wiki? Mark Conrad >> (All): Will do! JohnGarrett >> (All): How about we meet next monday. Then we'll look at areas Simon identified as needing review, 7.1, 7.2, 9.2 JohnGarrett >> (All): bye for now BruceAmbacher >> (All): ok RobertDowns >> (All): Bye Mark Conrad >> (All): I will see you all in two weeks. Bye. From tibbo at email.unc.edu Wed Sep 30 11:17:16 2009 From: tibbo at email.unc.edu (Helen Tibbo) Date: Wed Sep 30 11:10:03 2009 Subject: [Moims-rac] Choice of day In-Reply-To: References: Message-ID: <001501ca41e1$187183e0$49548ba0$@unc.edu> Sorry for joining then immediately leaving today. Lost the connection then whisked into something else. -Helen Dr. Helen R. Tibbo School of Information and Library Science 201 Manning Hall CB#3360 University of North Carolina at Chapel Hill Chapel Hill, NC 27599-3360 Tel: 919-962-8063 Fax: 919-962-8071 Email: tibbo@email.unc.edu -----Original Message----- From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Mark Conrad Sent: Wednesday, September 30, 2009 11:02 AM To: moims-rac@mailman.ccsds.org Subject: Re: [Moims-rac] Choice of day David, Simon, Here is the chat from today's meeting. We agreed to meet next Monday at 10:30 am EDT. Mark Mark Conrad >> (All): Good morning. RobertDowns >> (All): Good morning! Terry Longstreth >> (All): Good Morning; so, we're all West of Noon? Mark Conrad >> (All): Bruce's e-mail indicated that we would be meeting at 10 today, but I thought the agreed time was 10:30 EDT. Does anyone else have any info? RobertDowns >> (All): I saw Bruce's message, too, but perhaps others did not see it. Terry Longstreth >> (All): I think David was implying we use Bruce's time for today only. Mark Conrad >> (All): Agreed, but I think the time Bruce listed in his e-mail was not the time we agreed for today at the last meeting. Unfortunately the minutes from the last meeting have not been posted. I am sending out an e-mail message to the list to see when other people thought we are meeting today. Terry Longstreth >> (All): Fine. In the meantime, where do I find a copy of ISO ISO/IEC 17021:2006 to understand the references ? Mark Conrad >> (All): I have a copy on loan from David. He may be able to provide you with a copy. Mark Conrad >> (All): Should we try back at 10:30 and see if anyone shows up then? Terry Longstreth >> (All): OK Mark Conrad >> (All): See you later! RobertDowns >> (All): ok RobertDowns >> (All): Hi Bruce BruceAmbacher >> (All): Hi Robert. BruceAmbacher >> (All): When I find a few idle minutes I will send out the beginnings of a grant proposal - 3 years, experts meeting, promotion, training of auditors, conducting first audits, etc. IMLS has asked about this standard which might be interpreted as an interest in funding BruceAmbacher >> (All): As you can see above a few met at 10:00, disbanded and agreed to return at 10:30 RobertDowns >> (All): That's great Bruce. I look forward to seing it. RobertDowns >> (All): Yes, I was in the earlier group, too, but we decided to try again at 10:30 BruceAmbacher >> (All): I will try to get Helen to write it. She has an amazing track record. RobertDowns >> (All): That seems like a good approach BruceAmbacher >> (All): I still have your earlier input and will use that. JohnGarrett >> (All): Hi, I of course missed the changed time and thought it was 10:30 today BruceAmbacher >> (All): John, BruceAmbacher >> (All): everyone is messed up as to time and day RobertDowns >> (All): And next week we go back to Mondays? JohnGarrett >> (All): Yes I believe we go back to Mondays next week. I'm unsure what time. Mark Conrad >> (All): According to David's note, that was to be determined at today's meeting. JohnGarrett >> (All): For me, Monday morning is probably the best RobertDowns >> (All): Monday morning might be better for me, too. BruceAmbacher >> (All): Gentlemen, I am like an old plowhorse. Once you let me out of harness it is very difficult to get me back in and working. BruceAmbacher >> (All): Monday would be good for me. JohnGarrett >> (All): Fine with me, BruceAmbacher >> (All): I suggest 10:30 EDT RobertDowns >> (All): 10:30 EDT would work for me Mark Conrad >> (All): That will work for me - except for next Monday. JohnGarrett >> (All): Works for me. Plan for an hour meeting to start? RobertDowns >> (All): An hour seems fine. Mark Conrad >> (All): Ok. BruceAmbacher >> (All): What part(s) of the auditors' handbook do we want to focus on next Monday? JohnGarrett >> (All): Is plan for meeting to just march through the currentlyh identified areas to look at and decide to keep or throw out or add criteria? BruceAmbacher >> (All): John, Any hints as to when the standard will emerge from tech. editing? Mark Conrad >> (All): Bruce, You had comments on some sections already. Should we start with those? BruceAmbacher >> (All): OK. I just have to find them again. JohnGarrett >> (All): No, I thought it would be out by now. We of course had the problem with the security section that's now taken care of, but I thought that was the only hold up. JohnGarrett >> (All): I'm attending another video conference today regarding status of CCSDS WGs. Maybe I can get some info then if the CCSDS editor is on-line. BruceAmbacher >> (All): John, does anything happen between its emergence and when it circulates for international comment? BruceAmbacher >> (All): Welcome Helen, how is your semester going? Helen Tibbo >> (All): Hello - I am unprepared today - no headphone BruceAmbacher >> (All): Helen, interesting. You show up as having an active mike. JohnGarrett >> (All): I don't think so, but I don't know if the CCSDS and ISO reviews are simultaneous or in series. Regardless we'd like to get all the comments during the CCSDS review if possible so the ISO will just be a formality. Terry Longstreth >> (All): a new note from David.. he won't be on today. Nor Simon BruceAmbacher >> (All): Helen, we have agreed to "meet" on Monday starting at 10:30 EDT Mark Conrad >> (All): So are we doing anything else today or just regrouping and reconvening next Monday? BruceAmbacher >> (All): I vote for regrouping Monday. Mark, will you please capture text and submit to simon or wiki? Mark Conrad >> (All): Will do! JohnGarrett >> (All): How about we meet next monday. Then we'll look at areas Simon identified as needing review, 7.1, 7.2, 9.2 JohnGarrett >> (All): bye for now BruceAmbacher >> (All): ok RobertDowns >> (All): Bye Mark Conrad >> (All): I will see you all in two weeks. Bye. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac From waltz at crl.edu Wed Sep 30 11:43:35 2009 From: waltz at crl.edu (Marie Waltz) Date: Wed Sep 30 11:15:18 2009 Subject: [Moims-rac] Choice of day In-Reply-To: References: Message-ID: <9E612AEEF6ADB74A8690EC3F91B79C84017BB7CF@crlexchange.LAN_DOMAIN.EDU> Thanks Mark. Marie -----Original Message----- From: moims-rac-bounces@mailman.ccsds.org [mailto:moims-rac-bounces@mailman.ccsds.org] On Behalf Of Mark Conrad Sent: Wednesday, September 30, 2009 10:02 AM To: moims-rac@mailman.ccsds.org Subject: Re: [Moims-rac] Choice of day David, Simon, Here is the chat from today's meeting. We agreed to meet next Monday at 10:30 am EDT. Mark Mark Conrad >> (All): Good morning. RobertDowns >> (All): Good morning! Terry Longstreth >> (All): Good Morning; so, we're all West of Noon? Mark Conrad >> (All): Bruce's e-mail indicated that we would be meeting at 10 today, but I thought the agreed time was 10:30 EDT. Does anyone else have any info? RobertDowns >> (All): I saw Bruce's message, too, but perhaps others did not see it. Terry Longstreth >> (All): I think David was implying we use Bruce's time for today only. Mark Conrad >> (All): Agreed, but I think the time Bruce listed in his e-mail was not the time we agreed for today at the last meeting. Unfortunately the minutes from the last meeting have not been posted. I am sending out an e-mail message to the list to see when other people thought we are meeting today. Terry Longstreth >> (All): Fine. In the meantime, where do I find a copy of ISO ISO/IEC 17021:2006 to understand the references ? Mark Conrad >> (All): I have a copy on loan from David. He may be able to provide you with a copy. Mark Conrad >> (All): Should we try back at 10:30 and see if anyone shows up then? Terry Longstreth >> (All): OK Mark Conrad >> (All): See you later! RobertDowns >> (All): ok RobertDowns >> (All): Hi Bruce BruceAmbacher >> (All): Hi Robert. BruceAmbacher >> (All): When I find a few idle minutes I will send out the beginnings of a grant proposal - 3 years, experts meeting, promotion, training of auditors, conducting first audits, etc. IMLS has asked about this standard which might be interpreted as an interest in funding BruceAmbacher >> (All): As you can see above a few met at 10:00, disbanded and agreed to return at 10:30 RobertDowns >> (All): That's great Bruce. I look forward to seing it. RobertDowns >> (All): Yes, I was in the earlier group, too, but we decided to try again at 10:30 BruceAmbacher >> (All): I will try to get Helen to write it. She has an amazing track record. RobertDowns >> (All): That seems like a good approach BruceAmbacher >> (All): I still have your earlier input and will use that. JohnGarrett >> (All): Hi, I of course missed the changed time and thought it was 10:30 today BruceAmbacher >> (All): John, BruceAmbacher >> (All): everyone is messed up as to time and day RobertDowns >> (All): And next week we go back to Mondays? JohnGarrett >> (All): Yes I believe we go back to Mondays next week. I'm unsure what time. Mark Conrad >> (All): According to David's note, that was to be determined at today's meeting. JohnGarrett >> (All): For me, Monday morning is probably the best RobertDowns >> (All): Monday morning might be better for me, too. BruceAmbacher >> (All): Gentlemen, I am like an old plowhorse. Once you let me out of harness it is very difficult to get me back in and working. BruceAmbacher >> (All): Monday would be good for me. JohnGarrett >> (All): Fine with me, BruceAmbacher >> (All): I suggest 10:30 EDT RobertDowns >> (All): 10:30 EDT would work for me Mark Conrad >> (All): That will work for me - except for next Monday. JohnGarrett >> (All): Works for me. Plan for an hour meeting to start? RobertDowns >> (All): An hour seems fine. Mark Conrad >> (All): Ok. BruceAmbacher >> (All): What part(s) of the auditors' handbook do we want to focus on next Monday? JohnGarrett >> (All): Is plan for meeting to just march through the currentlyh identified areas to look at and decide to keep or throw out or add criteria? BruceAmbacher >> (All): John, Any hints as to when the standard will emerge from tech. editing? Mark Conrad >> (All): Bruce, You had comments on some sections already. Should we start with those? BruceAmbacher >> (All): OK. I just have to find them again. JohnGarrett >> (All): No, I thought it would be out by now. We of course had the problem with the security section that's now taken care of, but I thought that was the only hold up. JohnGarrett >> (All): I'm attending another video conference today regarding status of CCSDS WGs. Maybe I can get some info then if the CCSDS editor is on-line. BruceAmbacher >> (All): John, does anything happen between its emergence and when it circulates for international comment? BruceAmbacher >> (All): Welcome Helen, how is your semester going? Helen Tibbo >> (All): Hello - I am unprepared today - no headphone BruceAmbacher >> (All): Helen, interesting. You show up as having an active mike. JohnGarrett >> (All): I don't think so, but I don't know if the CCSDS and ISO reviews are simultaneous or in series. Regardless we'd like to get all the comments during the CCSDS review if possible so the ISO will just be a formality. Terry Longstreth >> (All): a new note from David.. he won't be on today. Nor Simon BruceAmbacher >> (All): Helen, we have agreed to "meet" on Monday starting at 10:30 EDT Mark Conrad >> (All): So are we doing anything else today or just regrouping and reconvening next Monday? BruceAmbacher >> (All): I vote for regrouping Monday. Mark, will you please capture text and submit to simon or wiki? Mark Conrad >> (All): Will do! JohnGarrett >> (All): How about we meet next monday. Then we'll look at areas Simon identified as needing review, 7.1, 7.2, 9.2 JohnGarrett >> (All): bye for now BruceAmbacher >> (All): ok RobertDowns >> (All): Bye Mark Conrad >> (All): I will see you all in two weeks. Bye. _______________________________________________ Moims-rac mailing list Moims-rac@mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-rac