10.1 Introduction
This section provides sample generic CALS Statement of Work (SOW) language and CALS source selection criteria to assist the acquisition manager in the implementation of CALS for a Project.
10.2 How to contract for CALS - Sample Statement of Work Language and Source Selection Criteria
10.3 Statement of Work Language
This Generic Statement of Work (SOW) provides sample language to assist in the implementation of Continuous Acquisition and Life-cycle Support (CALS). The content within each sample paragraph should be tailored for each application. This CALS-related language should be used in developing the functional requirements within each applicable section of the Request For Proposal (RFP) or Request for Quotation (RFQ) SOW. A more detailed sample SOW for development of a CITIS is contained in section 5.
Text appearing as [ times roman italics] in the following paragraphs is provided as the language that would be used in the actual SOW. Text appearing as [Small Caps] within the actual SOW text indicates information input by program managers relevant to their programs.
10.3.1 Scope
The contractor shall establish a digital technical information (TI) system to provide automation and integration of the generation, delivery, and uses of [Program name] technical information over the ["DEFENSE System" or "Equipment"] life-cycle. Unless otherwise specified within the contract, all, or any portion of, the technical information (TI) specified herein shall be developed in a digital form compatible with requirements stated herein. Unless specifically stated herein, the following requirements do not replace or amend requirements for delivery of TI in non-digital forms specified elsewhere in the contract.
10.3.2 Specific Requirements
The contractor shall implement a CALS Program that will achieve the following objectives:
· Integrate contractor technical information systems and processes;
· Authorize NATO/NATO nations access to the contractor database(s);
· Deliver technical information in digital forms."
10.3.3 CALS Implementation Plan
The contractor shall develop and maintain a current, comprehensive and detailed CALS Implementation Plan (CALSIP) outlining the procedures to be used to accomplish the CALS requirements defined in [Section X.X] of this Statement Of Work (SOW). The CALSIP shall address capabilities for automating the access and retrieval of technical data, and provide for digital exchange and integration between the engineering, manufacturing, logistics, and other functional areas as appropriate to this acquisition phase of the Program.
The CALSIP shall address, as a minimum, the following:
CALS support hardware and software architecture, reference documents, and points of contact.
· Contractor's approach and experience in creation, management, use, and exchange of digital information.
· Contractor's capabilities for integrating applications and databases.
· Procedures to improve product quality and eliminate data redundancy.
· Proposed CITIS on-line access capabilities.
· Information system and relationships with NATO/NATO nations receiving systems.
· Outline of proposed actions and capabilities to be pursued in subsequent life-cycle phases.
· Telecommunications data protection and integrity, including system security."
10.3.4 CALS Approach
The contractor shall define a specific CALS implementation objective and strategy, taking into consideration technical constraints, quality and cost guidelines and the NATO/Government CALS Concept of Operations (NCoO) established by the service acquisition manager. This strategy shall be supported by necessary trade studies, and shall describe the framework for CALS implementation activities to be accomplished during each phase of [Program name] system development. The strategy shall define how the principles of Concurrent Engineering (CE) will be applied, identify the critical enablers for CE (i.e., integrated database), and provide details on how Program risk and costs will be reduced and product quality improved through CE and CALS initiatives. The implementation strategy shall serve as a guide in developing contractual requirements for later Program acquisition phases. The CALSIP shall be updated every [days] throughout the life of the contract. The CALSIP updates shall define implementation plans for the upcoming period in greater detail, resolve outstanding strategy issues, respond to strategic and technology changes, and recommend specific alternative approaches for continuation of CALS in the next phase.
10.3.5 Database Architecture/System Tradeoffs
The contractor plan shall provide a cost effective method of managing the utilization of the contractor set of automated data processing systems and applications which support specific weapon system technical database(s) such that appropriate configuration and version control of technical information is maintained, while providing current data for design, engineering analysis, manufacturing, and product support planning. The contractor shall conduct appropriate tradeoffs/studies/analyzes to support determination of the CALS implementation strategy. The status of these studies shall be reviewed at appropriate Program management, design, and ILS reviews, and the results documented as part of the CALSIP. Candidates for such studies include:[Examples only; final determination is Program specific]
· Improved alternate data generation and delivery modes.
· Digital data delivery vs. on-line access.
· Identification and elimination of unnecessary CDRL items.
· Identification of CDRL items for interactive, on-line review.
· Analysis of telecommunication alternatives.
· Functional integration cost/benefit studies.
· Cost effectiveness of contractor interim.
CALS support [particularly in areas where infrastructure capability limitations can be overcome through use of hardware/software leased from the contractor]."
10.3.6 CALS Standards Conformance Test
The contractor shall include in the CALSIP plans to demonstrate the exchange of digital deliverables using the CALS standard formats, in accordance with the requirements of [ xxx ] and references [ xxx ]. This shall be accomplished through testing provided by the NATO/NATO nations or an industrial organization(s) chartered to perform such conformance test. Deliverables should pass a first article test on all formats to ensure conformance to the CALS specifications."
10.3.7 Security
The contractor shall establish a security system and enforce data protection and integrity standards. System security engineering principles as outlined in [ xxx ] shall be used. Controls to prevent unauthorized access shall be established and detailed in the CALSIP. The plan shall be based on the results of documented data protection and integrity, threat and vulnerability analysis, risk assessments, and tradeoff analyzes. Vulnerabilities that remain after security system design shall be identified. The plan shall include disaster recovery provisions. Security requirements that must be complied with by NATO/NATO nations personnel will be identified to the NATO/NATO nations in the security section of the CALSIP. Any peculiar software that must be resident on NATO/NATO nations access terminals will be provided and maintained by the contractor. Information requiring special security provisions such as classified data, critical technology and sensitive data, such as proprietary, competition or liability sensitive data, will be partitioned to minimize the volume of information requiring specialized handling, to provide classification at the lowest classification level, and to control access. Sensitive data, in this context, includes but is not limited to, CDRL data items marked with one or more of the following: an export control warning notice, restrictive distribution statement, and/or a proprietary legend. Encryption of classified data or sensitive military data shall be stipulated by the CDRL and on an as-required basis in accordance with procedures established by the [ xxx ]. Such information shall be identified to prevent inadvertent disclosure and retention of security identification for printouts of accessed information. The contractor shall pay particular attention to unclassified items of information, which, taken together, can infer classified information. The contractor shall maintain configuration control of the security system and trusted system components. The contractor shall conduct a test and evaluation of the system and periodic inspections to ensure compliance. The NATO/NATO nations shall retain the right to conduct announced and unannounced inspections by security specialists at any time to review, audit, and account for classified materials.
10.3.8 Program Assessment and Control
The CALSIP shall describe the procedures and controls by which the contractor and the NATO/NATO nations will evaluate the status and effectiveness of CALS. The implementation of CALS will be a subject of review at program, design, and ILS reviews.
10.3.9 Post Award CALS Program Orientation Conference
The prime contractor shall host a post award CALS program orientation conference to be scheduled no later than [number] of days after contract award. A representative from the [program name] program office shall chair this conference. Major prime contractor teaming partners/subcontractors shall attend. The agenda for this conference shall be approved by the [program name] program office. The purpose of this CALS meeting is to clarify the NCoO and have the contractor present to the NATO/NATO nations their plans for on-line access, if required, exchange, and delivery of digital data."
10.3.10 Government Furnished Information
The contractor CALSIP shall describe the Government Furnished Information (GFI) the contractor expects to receive from the NATO/NATO nations. The list of GFI the NATO/NATO nations plans to provide is included in attachment/exhibit [number]. GFI shall be provided in both digital and hard copy formats. The GCO will define infrastructure capabilities to receive and use various types of digital data and technical information. The contractor shall use this GFI with contractor generated data."
10.3.11 Contractor Integrated Technical Information Services)
The contractor shall propose ["develop" if CITIS is required] a program composed of procedures, processes, specifications, and software applications for the integration, storage, exchange, and/or on-line sharing of data with the NATO/NATO nations. These technical data and database(s) and functional application capabilities provided within the contractor's system shall be referred to as Contractor Integrated Technical Information Services (CITIS). This CITIS shall be developed in accordance with [ xxx ], and the following. The contractor shall propose ["develop" if CITIS is required] a Technical Information (TI) and program management architecture, with a functional and hierarchical indexing system to:
· Manage configuration of the entire TI and planning databases.
· Integrate planning information into its respective TI source database.
· Trace configuration changes from design to logistics products and vice versa.
The contractor shall propose how he will ["is required to" if CITIS is required ] establish a link among logistics, design, engineering, and manufacturing data and functional processes to:
· Facilitate the interchange and exchange of technical information.
· Integrate technical data and database(s) to support the design, manufacturing and support processes and allow for timely access by authorized NATO/NATO nations activities.
· Provide an integrated, shared data environment, consisting of integrated databases, analysis tools, and engineering processes designed to utilize digital TI.
· Provide for the generation, storage, indexing, distribution, and delivery of integrated acquisition and logistics information products.
In the selection of analytical tools, the contractor shall maximize the use of previously developed or off-the-shelf software. These software tools shall be compatible with NATO/NATO nations hardware/software systems stated in the NCoO, unless contractor developed, unique software solutions are demonstrated to be more cost effective. The contractor's telecommunications solution for CITIS shall comply with NATO/NATO nations Interconnect Profile.
10.3.12 Data Element Dictionary [If CITIS is required.]
A general data element dictionary shall be developed so that identical data elements are addressable by the computer as the same data element. Changes to any duplicate data element shall be effected throughout all databases. A similar methodology shall be developed for graphics and large textual entities to ensure that changes to the source graphic correctly flags the necessity for change to all dependent graphic/textual entities derived from the source graphic. The contractor shall use existing data dictionaries as guidance in constructing the [Program] data dictionary.
10.3.13 Engineering Data (Graphic and Text Files)
Any data, either NATO/NATO nations, contractor, or vendor, that contains engineering definition or guidance on material items (components), equipment system practices, methods, and/or processes relating to the design, manufacture, acquisition, test, inspection shall be submitted in digital form in accordance with [ XXX ] and compatible with the NATO/NATO nations data repository and receiving systems stated in the NCoO.
10.3.14 Automation and Functional Integration
The contractor should use computer-aided design, engineering, and manufacturing methods (CAD/CAE/CAM) to support design integration with manufacturing planning and logistic support system development. These software tools shall be compatible with the NATO/NATO nations hardware/software systems stated in the NCoO, unless contractor developed, unique software solutions are demonstrated to be more cost effective. An integrated set of ADP systems and applications will be used by the contractor team to enter, update, manage, and retrieve data from specific [Program] technical database(s)."
10.3.15 Reliability and Maintainability Automation
The contractor shall employ automated tools for performing Reliability and Maintainability (R&M) tasks. The contractor shall integrate these R&M tools with other CAE tools. These tools may stand-alone with no direct access to the CAE database; reside in the CAE system and interface with the evolving design; or, reside on the CAE system and be automatically invoked to support design decisions. The R&M methods and tools used by the contractor shall include, as a minimum:
· Automated R&M analysis procedures coupled to parts libraries and to material characteristics databases.
· Automated R&M synthesis based on design rules and lessons learned from prior design experience and field use.
· Fully characterized (tested and validated) component part performance and R&M characteristic databases.
· Design decision traceability.
10.3.16 R&M-Logistic Support Analysis Record Integration
The contractor shall establish an automated link to satisfy Logistic Support Analysis Record (LSAR) documentation requirements for initial and updated reliability and maintainability (R&M) information. Algorithms or transformations that must be applied to R&M source data elements to conform to LSAR documentation requirements shall be documented. Traceability between the LSAR and individual R&M data sources, and the preservation of appropriate data flows while maintaining established LSAR data element relationships and interdependencies, shall be clearly demonstrated.
10.3.17 LSAR Data Automation
The contractor shall establish and maintain a validated LSAR automated data processing system capable of input, storage, and retrieval of LSAR data in accordance with [xxx]. The contractor may use an internally developed and NATO/NATO nations validated LSAR automated data processing system, or independently developed and NATO/NATO nations validated LSAR automated data processing system. The contractor shall partition LSAR working data for in-process reviews and maintain these files separate from NATO/NATO nations approved LSAR data. The LSAR version containing the submitted data shall be the LSAR that has been subjected to internal contractor review procedures and is pending NATO/NATO nations review and approval. The LSAR working data shall be updated in accordance with the schedule in the LSA plan regardless of the approval status of the working data's content since the last update. Upon NATO/NATO nations approval, LSAR working data shall be transferred to the NATO/NATO nations approved LSAR. All NATO/NATO nations directed changes resulting from the LSAR data shall be cumulative of all approved LSAR data. Delivery of LSAR data shall be in accordance with the CDRL.
10.3.18 Reliability Centered Maintenance and Age Exploration Automation
The contractor shall develop an automated system to maintain a complete Reliability Centered Maintenance (RCM) audit trail throughout the [Program name] life-cycle. This audit trail will permit traceability of preventive maintenance tasks back to specific engineering failure modes listed in the LSAR. The automated RCM analysis process must have the capability of delivering results digitally and through an interactive electronic interface with the LSAR database. The contractor shall utilize the RCM automated worksheet process or a contractor developed RCM automated process with the capability of automatically transferring compatible data to the NATO/NATO nations RCM software. The automated RCM analysis data/work-sheets must be delivered to the NATO/NATO nations in accordance with the CDRL.
The contractor will develop an Age Exploration (AE) database for the storage and analysis of in-service/operational age-reliability data that shall be used to support the RCM analysis process. The AE database shall be integrated digitally and have an interactive electronic interface with the RCM automated process.
10.3.19 Level of Repair Analysis
The contractor shall employ an automated system to perform Level of Repair Analysis (LORA) in accordance with the requirements specified in [xxx]. The contractor shall establish a database as a repository for LORA input data and LORA output report files generated by execution of the LORA model software. The LORA database will be integrated with the automated LSAR database to maintain traceability of LSA data used as input to the LORA. The output results of the LORA shall be documented in the LSAR for development of the LSA-024 maintenance plan report. Approved LORA input data files and output reports shall be delivered in accordance with CDRL specified delivery mode (i.e., deliverable digital media or on-line access/retrieval).
10.3.20 Diagnostics
The source of diagnostic information will reside in logistics engineering databases offering data exchange in neutral formats. Software shall be developed to provide for automated interface with in-service performance and maintenance data collection processes and to provide feedback concerning successes and failures in the fault isolation process to the [Program] system designer. Diagnostic systems that learn from experience and which have the capability to update a knowledge-based diagnostic database to optimize the fault isolation process or to improve system design are to be used to the fullest extent possible.
10.3.21 Management Information Tools
The contractor shall establish an on-line direct access capability for recording, planning, scheduling, and reporting status of program requirements. This shall provide visibility of the contractor's performance, highlight potential problems, and provide schedule compatibility checks to ensure integration of functional activities. This on-line capability shall identify change impacts on related areas of logistic support, design and manufacturing, and provide the status of program deliverables.
10.3.22 Technical Manuals
The contractor shall provide for computer assisted generation of technical manuals. This data is to be derived, to the maximum extent possible, from integrated digital data files, e.g., CAD/Engineering Database/LSAR. This data shall be provided in accordance with (Service-unique specifications and TM development guidance or other TM SOW requirements).
10.3.23 Supply Support
The contractor shall maintain spare parts identification consistent with the approved configuration baseline and allow for on-line assessment of the impact to spare parts requirements during analysis of design alternatives. The contractor shall provide provisioning technical documentation in accordance with [ xxx ] to facilitate automated ordering, supply management, and distribution, and should provide on-line identification of spares, repair parts, and source/maintenance/recoverability coding. This data shall be provided IAW (Service-unique specifications and TM/TO development guidance or other TM/TO SOW requirement).
10.3.24 Facilities Data
The contractor shall provide facilities data in digital form in accordance with [ xxx ] consistent with data derived from the LSAR database. Engineering drawings and specifications shall be provided in accordance with [ xxx ].
10.3.25 Training
Training data should be developed in accordance with [xxx]. The LSAR database shall provide source data to program software for producing output reports and instructional materials. Authorized system software shall be in accordance with NCoO specified requirements.
10.4 Source Selection Criteria
A key process for creating a Solicitation (i.e., Request for Proposal [RFP] or Request for Quote [RFQ]) is the data call. This process identifies and develops specific NATO/NATO nations requirements for data (Contract Data Requirements List [CDRL]).
CALS related issues are made manifest during the data call via the NATO/NATO nations Concept of Operation (NCoO) questionnaire responses. Only then can CALS be taken beyond a strategy to become a value added reality. CALS must continue to be emphasized during the contract development phase, as incentives for CALS are incorporated into both the draft contract and the Source Selection Plan, to guide the follow-on proposal evaluation phase.
10.4.1 Source Selection for CALS
The following elements aid in CALS-presence throughout source selection:
· Ensure that technical requirements facilitate CALS utilization;
· Encourage industry identification of CALS alternatives;
· Provide positive incentives in Evaluation Criteria section;
· Make CALS an explicit element of Source Selection Plan;
· Provide/ensure CALS awareness of Source Selection Evaluation Board.
10.5 Guidelines and Sample Clauses for Electronic Data Interchange
10.5.1 Introduction
The state of development of EDI, although maturing in terms of implementation and message standards, still requires flexible tools and guidelines to maintain the highest growth momentum. The objective of the sample clauses offered in this section is to provide both Ministry of Defense and NATO Agency with a concrete and pragmatic tool which addresses the basic legal and contractual issues raised by the use of EDI. Those sample clauses will appear in the following paragraphs as [ Times Roman Italics].
| The authoritative source for clauses to be included in contractual documents is AC/313. |
The authoritative source for clauses to be included in contractual documents is AC/313. That committee has published the guidelines from which the following samples are drawn. The following are examples only, offered to assist in understanding the issues involved. The ones implementing such agreements should refer to the latest AC/313 guideline document.
These examples are offered for application in situations where a signed document needs to be established between a ministry or an agency and its trading partners with respect to data that are going to be electronically exchanged, but they do not apply to database access. Ministries and agencies may consider it appropriate to envelop the electronic interchange of data within a legally binding framework, so that the obligations of the signatories towards each other are clearly seen to be enforceable. Some nations, on the other hand, may choose not to use a legally enforceable, signed, format to set down these obligations; they may choose instead to lay down the principles concerned in law or regulations, depending on the characteristics of their legal code. Nevertheless, extracts from these sample clauses may be appropriate for use in the development of such laws and regulations.
Different legal issues have been identified with the use of Electronic Data Interchange for the purposes of commercial transactions or similar commercially sensitive transactions, or other data exchange with legal consequences. Although these issues do not prevent the use of Electronic Data Interchange, they create legal uncertainty. One of the most pragmatic ways to address these issues is to resolve them, to the extend possible, in a legal framework. The objective of these sample clauses is to provide the Electronic Data Interchange users with a tool that addresses these legal issues. In general, the samples are provided for bilateral relationship. However, the samples can also be used for multilateral agreements and/or can be adopted by a community of users.
The legal provisions should be signed by the parties to show that they intend to enter into an agreement. The samples provided address all issues to cover an EDI relationship between parties. Subsequent rights and obligations and the legal consequences of the use of EDI between the parties will derive from the Agreement thus formed.
| Legal consequences of the use of EDI between parties will derive from the signed Agreement |
The sample clauses are intended to cover all the subjects to be addressed under an electronic data interchange relationship, including electronic mail. The guidelines and sample clauses cover a wide range of electronic exchange of data, from electronic mail to the ultimate Electronic Data Interchange, which is the transfer of data from computer to computer without human involvement.
The transfers involved can vary from commercial trade transactions under an Integrated Logistic Support program (e.g., ordering spare parts from contractor stock) to exchange of proprietary data when developing a weapon system data base.
Some of the clauses include general references to technical matters. These technical matters require further specifications. They are often found in so-called "user manual." The samples need to be completed by a User Manual that will include the necessary technical specifications as determined by the parties. The User Manual is left to the Electronic Data Interchange users to develop, draft and/or agree according to their needs.
10.5.2 Agreement First Page
The first page should incorporate sufficient information to provide a capsule of the most salient points of the Agreement at a glance. Such items of information may include:
· Reference number
· Identification of the parties to the agreement, their representatives and their addresses
· Security classification
The data exchanged can be of different nature. It can be of a commercial nature or of an administrative one. In some cases, the exchange of technical information of a confidential nature can be involved. The "whereases" can elaborate on the nature of the transactions involved. In case of a dispute, these considerations might be helpful.
Sample Clauses
ELECTRONIC DATA INTERCHANGE AGREEMENT
(including Electronic Mail)
[Reference Number]
Agreement concluded by and between:
the Minister of Defense of _______________ /NATO Agency
and ___________________________________________________
hereinafter referred to as "the parties," now therefore have reached the following agreement, hereinafter referred to as "the Agreement."
10.5.3 Object and Scope
It should be emphasized that the Agreement constituted by the sample clauses only governs the EDI relations between the parties and that it is not intended to govern the substance of transactions that will effectively be carried out using Electronic Data Interchange. The issues of validation and formation of the underlying agreement are covered by the sample clauses on validity and formation of the contract. Conflicts or inconsistencies between the agreements involved should be prevented.
Sample Clauses
This Agreement specifies the terms and conditions under which the parties, conducting transactions by the use of Electronic Data Interchange, operate.
The Agreement consists of the Provisions set out in the following and shall be completed by a USER MANUAL that is made part of the Agreement.
Unless otherwise agreed by the parties, the provisions of the Agreement are not intended to govern the contractual obligations arising from the underlying transactions effected by the use of Electronic Data Interchange, except for the validity and formation of such transactions as stipulated in clauses VALIDITY AND FORMATION OF CONTRACT and ADMISSIBILITY IN EVIDENCE OF ELECTRONIC DATA INTERCHANGE MESSAGES of this agreement.
10.5.4 Definitions
Inserted in this clause are the basic definitions used in the sample clauses. They aim at ensuring an unambiguous understanding of these terms used in the Agreement.
ACKNOWLEDGMENT OF RECEIPT
As there are different kinds of acknowledgement of receipt of an EDI Message, it is essential to indicate clearly, which level of acknowledgment is referred to, in order to avoid confusion. This definition reflects the level chosen within the agreement in particular as it is referred to in clause
PROCESSING AND ACKNOWLEDGMENT OF RECEIPT OF ELECTRON IC DATA INTERCHANGE MESSAGES.
EDI Message
EDI is based on the use of structured and coded messages, the main characteristic of which is their ability to be processed by computers and transmitted automatically and without ambiguity. This definition emphasizes these essential characteristics, which make EDI specific in comparison with other data exchange such electronic mail.
Sample Clauses
DEFINITIONS
For the purpose of this Agreement, the following terms are defined as follows:
Acknowledgement of receipt: the procedure by which, on receipt of the EDI Message, the syntax and semantics are checked, and a corresponding acknowledgement is sent by the receiver.
Authentication: criteria permitting the receiver to verify that it is an authentic document by sender.
Business day: any day except a Saturday, Sunday or any declared public holiday in the intended place of receipt of an EDI Message as defined in the User Manual.
Data-log: a collection of data transferred that provides a complete historical record of data interchanged.
Electronic Communications: the communications of digital data by electronic means such as but not limited to telephone, telefax, computer-to-computer-link.
Electronic Data Interchange (EDI): is the electronic transfer of data, from computer to computer, using an agreed standard to structure an EDI Message.
EDI Message: a set of segments, structured using an agreed standard, prepared in a computer readable format and capable of being automatically and unambiguously processed, as defined in the User Manual.
Electronic Data Interchange Protocol: the protocol specified by the parties hereto as that governing the requirement of format, structure and transmission of documents and other communication between the Parties via the Electronic Data Interchange network.
Electronic Mail: the electronic communication between the Parties of textual binary and graphical data in a non structured format, of a maximum size as specified in the User Manual.
Electronic Signature: an agreed string of characters identifying the originator of an EDI or Electronic Mail message.
Functional Acknowledgement: an acknowledgement message of the receiving Party's computer software application that automatically confirms the receipt of the Electronic Data Interchange document or Electronic Mail message at the moment of receipt.
Garbled Transmission: an attempted transmission that cannot be decoded by the receiving Party's host software application and is therefore completely or partially unreadable.
User Manual: the technical procedures and rules applicable to the transmission of data.
10.5.5 Authenticity of Messages
The parties should provide for the identification of the sender and the receiver together with means to verify the authenticity of the message.
Sample Clauses
All Electronic Data Interchange or Electronic Mail Messages must identify the sender and receiver and must include an agreed means of verifying the authenticity of the message either through a technique used in the message itself or by some other means provided for in the Electronic Data Interchange Protocol, or as specified in the User Manual.
Simultaneously with the execution of this Agreement, each Party shall furnish to the other, a list of the individuals authorized by it to send Electronic Data Interchange or Electronic Mail Messages and the appropriate Electronic Signature and shall update this list as necessary.
10.5.6 Validity and Formation of Contract
10.5.6.1 Validity of the Contract
This sample clause attempts to emphasize the intention of the parties to form valid and binding contracts by EDI and to provide proof of this intention to third parties. As such, the provision provides that parties will not challenge the validity of transactions effected by use of EDI, on the sole ground of that means.
The law applicable to the data transferred might be different from one country to the other and the parties may not necessarily be aware of national law restriction on the content of an EDI Message. It is reasonable to ensure that parties will take care to respect the national legislation applicable to the content of the EDI Message.
Whenever the data included in an EDI Message received is inconsistent with national law of the receiver, the obligation on him will be to inform the other party of this inconsistency and he may then be able to take measure to avoid breach of its own law.
Sample Clauses
The parties bound by the Agreement, expressly waive any rights to contest the validity or enforceability of a contract, affected by the use of EDI in accordance with the terms and conditions of the Agreement, or the authenticity of an Electronic Signature on the sole ground that it was affected by EDI.
The Parties agree not to contest the authenticity admissibility or enforceability of messages under the provisions of any applicable law relating to whether certain agreements are in writing and signed by the Party to be bound thereby.
Any Electronic Communications properly transmitted pursuant to this Agreement shall be considered to be "written" or "in writing." Any such message when containing, or to which there is affixed, and Electronic Signature shall be deemed to have been "signed" and to constitute a "true copy" when printed from electronic files or records established and maintained as specified in the clause on DATA-LOG: RECORDING, STORAGE AND RECONCILIATION OF ELECTRONIC DATA INTERCHANGE MESSAGES.
Each party shall ensure that the content of an EDI Message, sent or received, is consistent with the law of its own respective country, the application of which could restrict the content of an EDI Message or limit its use, and shall take all necessary measures to inform without delay the other Party if such an inconsistency arises.
10.5.6.2 Formation of the Contract
The following sample clause is related to the time and place where a contract is concluded or formed. The determination of the place and time of formation of a contract is important with regard to the legal consequences it involves. This sample clause implements the "reception rules" which ensure that acceptance takes place at the place and at the time of receipt of such acceptance by the offeror.
Sample Clause
The contract affected by the use of EDI shall be concluded at the time and place where the EDI Message constituting acceptance of an offer reaches the computer system of the offeror.
10.5.7 Admissibility in Evidence of EDI Messages
Following clauses are intended to clarify the parties' intention and ensure that legally binding contracts and related EDI process can be proved in the event of a dispute by the records maintained in conformity with the EDI agreement concluded.
The area of admissibility and evidential value is one where uncertainty is still predominant. As in most countries legal provisions regarding evidence are not mandatory, specifically in the commercial area, agreement between parties can be reached on the questions of evidence. By reaching an agreement between parties, this uncertainty can be partly reduced.
Effecting transactions by EDI as an alternative to paper implies that the EDI Messages will replace effectively the documents that were exchanged previously on paper. It implies that the parties can rely on these exchanges of messages to provide the evidence of the facts that have happened, in the case of a dispute.
Within the boundaries of national laws, especially mandatory law, which may apply and provided that the parties have respected the provisions of the agreement, these EDI Messages should be admissible before the courts as evidence and should also be recognized as a means to provide evidence of the facts that are recorded unless evidence to the contrary is provided.
To be admissible in court the evidence offered should be trustworthy and reliable. Good record-keeping, acknowledgment, and security provisions are factors that will affect admissibility of evidence.
Sample Clauses
To the extend permitted by law, the parties hereby agree that in the event of dispute, the records of EDI Messages, which they have maintained in accordance with the terms of this Agreement, shall be admissible before Courts and shall constitute evidence of the facts contained therein unless evidence to the contrary is adduced
Procedures to enable a secure means of archiving shall be detailed in the User Manual.
10.5.7.1 Processing and Acknowledgement of Receipt
10.5.7.2 Processing of Electronic Data Interchange Messages
The parties should commit themselves to deal with the EDI Messages they receive in a fixed time that should be specified in the User Manual. In the case where no time limit has been decided by the parties, they should process messages as soon as possible after receipt.
This provision is included, not only to ensure commercial efficiency and good business practices, but also in order to define the contractual rights and obligations of the parties in the event where a message is not received, is late or contains errors and the contract is thereby frustrated.
10.5.7.3 Acknowledgement of EDI Messages
The acknowledgement of receipt concept has often been misunderstood in particular with regard to the content of the EDI Message itself.
Different levels of acknowledgement are available. Acknowledgement can be automatically transmitted at the level of telecommunication network when the message is made available to the receiver,
It can be automatically sent upon the receipt of the EDI Message at the information system of the receiver without any verification, so called functional acknowledgement (see clause DEFINITIONS);
It can be sent after some verification has been achieved;
It can also mean, at some stage, acceptance of the content of the message or confirmation that the receiver will act on the content of the message.
The minimum level chosen (functional acknowledgment) does more than simply confirm the receipt. It corresponds to the level where verification of semantics and syntax is achieved and consists of a response to the EDI Message sent stating that the message has been received and that the syntax and semantics of the message are correct.
Parties may require other levels of acknowledgement, which in that case should be determined by them, according to their needs and the appropriate details should be included in the user manual. In that case distinctive levels of acknowledgement, i.e., acknowledgement of receipt, acknowledgement of receipt and verification, acknowledgement of receipt, verification and acceptation, need to be detailed in the user manual for the respective Electronic Data Interchange message or electronic mail.
A rejection is meant to ensure that the Electronic Data Interchange message sent should not to have any force or effect. The sending party should be informed of such a rejection in due time as defined in the user manual.
The principle stated in clause PROCESSING AND ACKNOWLEDGEMENT OF RECEIPT OF ELECTRONIC DATA INTERCHANGE MESSAGES is that an acknowledgement of receipt of an Electronic Data Interchange message is not required unless requested. However, data transmissions of a confidential nature or containing classified information need to be acknowledged in all cases.
Provision may also be made, in the User Manual, for all EDI Messages or for certain categories of messages (i.e., all "ORDER" messages) to be automatically checked and acknowledged.
Alternatively, if no specific provision has been made regarding acknowledgement, the appropriate segment for a request for acknowledgement may be included within a message sent.
Not all messages will require an acknowledgement and the User Manual should clearly differentiate between those that do and those that do not.
10.5.7.4 Time Limit and Acknowledgement of Receipt Transmission
EDI is characterized notably by an increased reliability due to a reduction in errors, faster and more accurate information flows and by increased automation of the processing of data. Acknowledgements contribute to the reliability and accuracy of EDI and time limits are in this context critical.
The importance of the time limit for sending the acknowledgement derives from the fact that the EDI Message may not be acted upon, and hence contractual obligations may not be carried out, until the acknowledgement, when required, has been sent.
One business day is deemed an appropriate time limit in the EDI environment. However, Just-in-Time management or other priorities may require more strict adjustment of time, or it may seem inappropriate or impractical and an extension might be required, in which case the parties should adjust the time limit and complete the EDI Agreement, as they will agree.
Although clause DEFINITIONS (paragraph above) provides a definition of a "business day," it may prove useful for the parties to specify more precisely the public or other holidays or the time of availability of the system.
An obligation to send an acknowledgement of an EDI Message is placed on the receiver, who should not act on the message, which requires an acknowledgement, until such acknowledgement has been sent.
10.5.7.5 Failure of Receipt of an Acknowledgement
In the case where an acknowledgement is not received by the sender of an EDI Message who has requested such an acknowledgement, within the applicable time limit, it is reasonable that he is allowed to assume that there has been a problem with the message or that the receiver does not want to, or cannot, deal with it and consequently that he should be able to consider such message as null and void provided he so advises the receiver. This latter condition will be particularly useful in a situation where a problem has occurred with the transmission of the acknowledgement. Time limits again will be critical.
Alternatively, the parties may determine a recovery procedure for the cases where technical problems have occurred and the sender of an EDI Message for which an acknowledgement is required may initiate such kind of recovery procedure if he does not receive the acknowledgement within the prescribed time limit. The details of such procedure should be determined in the User Manual.
10.5.7.6 Inability to Send Messages
Due to external circumstances, there may be an inability to transmit electronic communications from time to time. The parties may agree to exchange messages at such time by other methods of communication, including tele-copy, tele-facsimile, telephone, or paper. The legal implications of such alternative forms of communication should not be affected by the agreement.
Sample Clauses
EDI Messages shall be processed as soon as possible after receipt, but in any event, within the time limits specified in the User Manual.
If a message received appears not to be in good order, correct and complete in form, the recipient Party shall inform the other Party within the time limit as specified in the User Manual. If the message is rejected, a rejection message shall be sent within the time limit as specified in the User Manual
Immediately upon receipt of any EDI Message or Electronic Mail message at its receipt computer, the receiving Party's receipt computer shall automatically transmit a Functional Acknowledgement in return and additionally the sender may request the recipient to confirm the receipt of that message.
An acknowledgement of receipt is not required unless requested. However, acknowledgement is required for all trade data messages and messages containing classified data. An acknowledgement of receipt can also be requested by specific provision included in the User Manual or by express request of the sender in an EDI Message.
Where an acknowledgement of receipt is required, the receiver of the EDI Message to be acknowledged shall ensure that the acknowledgement is sent within one business day of the time of receipt of the EDI Message to be acknowledged, unless an alternative time limit has been specified in the User Manual. The receiver of an EDI Message requiring an acknowledgement shall not act upon the content of the EDI Message or further disclose or use its contents until such acknowledgment is sent.
If the sender does not receive the acknowledgement of receipt within the time limit applicable, he may, upon giving notification to the receiver to that effect, treat the EDI Message as null and void as from the expiration of that time limit or initiate an alternative recovery procedure as specified in User Manual, to ensure effective receipt of the acknowledgement. In case of failure of the recovery procedure, within the time limit, the EDI Message will definitely be treated as null and void, as from the expiration of that time limit, upon notification to the receiver.
A Garbled Transmission shall have no force or effect.
10.5.8 Security and Protection of EDI Messages
10.5.8.1 Obligations of Parties
A satisfactory level of security for messages must be ensured to avoid any risks that may be associated with the exchange of messages by EDI, and such level will depend upon the importance of the transactions or messages exchanged.
10.5.8.2 NATO Classified Information
For NATO classified information the NATO document C-M(55)15(Final) " Security within North Atlantic Organization" provides the necessary security requirements. In addition, national security regulations might be introduced here.
10.5.8.3 Security Procedures and Measures
Verification of origin and integrity are stated to be mandatory for any EDI Message as they constitute a basic level of security. Parties are, however, strongly recommended to agree, where required, on additional security measures, the degree of which will no doubt depend on the value and importance of the subject-matter of the messages and the possible security risks in the event of an unsuccessful exchange of messages.
Control measures should be provided in the user manual, possibly by reference to an agreed standard, such as specific checks, acknowledgement of receipt, control count, reference number, identification etc. More elaborate controls may be necessary, in particular when transactions are important and could mean the use of some specific messages to increase the security such as those recommended by security experts, or any other available security means or method, including, as an example, digital signatures.
The means, methods and specifications of security and the messages to be used between the parties, to ensure the level of security required, should be set out in detail in the user manual.
10.5.8.4 Failure and Security Procedures
The failure of an EDI Message exchange, or an error in a message resulting from the use of security procedures or measures should be notified to the sender within the specified time limits in order to allow the sender to initiate any appropriate corrective action. In the case of rejection of an EDI Message or the detection of an error, instructions from the sender should be sought before any other action is undertaken by the receiver on the content of message itself.
10.5.8.5 Encryption
The parties may agree to use a specific form of protection for certain message such as a method of encryption to the extent permitted by law in either of their respective countries. For consequential transmission or retransmissions, parties shall maintain the same level of protection.
Sample Clauses
The parties undertake to implement and maintain security procedures and measures in order to ensure the protection of EDI Messages against the risks of unauthorized access, alteration, delay, destruction, loss, or security breach.
The security classifications detailed in the User Manual shall apply. For NATO classified information the NATO document CM(55) 15(Final) "Security within North Atlantic Organization" is applicable. This document is made part of this Agreement by reference, automatically if the User Manual indicates that classified information will be transmitted.
Security procedures and measures include the verification of origin, the verification of integrity (including date and time of transmission), the non-repudiation of origin and receipt and the confidentiality of EDI Messages. Security procedures and measures for the verification of origin and the verification of integrity, in order to identify the sender of any EDI Message and to ascertain that any EDI Message received is complete and has not been corrupted, are mandatory for any EDI Message. Where required, additional security procedures and measures may be expressly specified in the User Manual.
If the use of security procedures and measures results in the rejection of, or in the detection of an error in an EDI Message, the receiver shall inform the sender thereof, within the specified time limit. The receiver of any EDI Message which has been rejected, or which contains an error shall not act upon the EDI Message before receiving instructions from the sender. Where a rejected or erroneous EDI Message is retransmitted by the sender, the EDI Message should clearly state that it is a corrected EDI Message.
10.5.9 Confidentiality
In-confidence information is distinguished from classified information by different laws and regulations relating to its disclosure and use and it should therefore be addressed separately in the agreement.
The level of protection to be maintained for Electronic Data Interchange messages of an in confidence nature is intended to reflect the level adhered to in the paper environment. At least the same level of protection of such messages should be maintained wherever such message is subject to consequential transmission or re-transmission. The contract covering the underlying transaction may provide for marking requirements (e.g., in respect of technical data). Any protective measures applied to such messages must be compatible with these requirements. The user manual may elaborate on the further technical procedures required to implement the necessary protection.
The information to be protected by this clause is sensitive information of a commercial nature. Accurate protection of this kind of information is mandatory. However, the restrictions required under this clause on the receiving party should not be applicable if the information is rightfully available for unrestricted use.
Sample Clauses
In addition to the provisions governing security the Parties shall ensure that Electronic Data Interchange Messages containing information specified by the sender or agreed mutually between the Parties to be of an in confidence nature are maintained in confidence and are not disclosed or transmitted to any unauthorized person nor used for any purposes other than those intended by the Parties. When authorized, further transmission of in confidence information shall be protected to at least the same degree as the originally transmitted Electronic Data Interchange Message. Data requiring protection shall be marked by the sender in accordance with the contract covering the underlying transaction and as defined in the User Manual.
Electronic Data Interchange Messages shall not be regarded as containing in-confidence information to the extent that it can be demonstrated such information:
· Is in the public domain other than by breach of this Agreement by the receiver and is available for unrestricted use; or
· Is in or comes rightfully into the possession of the receiver without restrictions; or
· Is received by the receiver from a third Party who himself has the right to disclose the information without restrictions; or
· Is or was independently developed by the receiver; or
· Is approved by the owner of the information for unrestricted release by the receiver.
10.5.10 Data-Log: Recording, Storage, and Reconciliation of EDI Messages
10.5.10.1 Storage Procedures and Time Limits
The requirements for storage of Electronic Data Interchange messages have in some countries been set up by legislation, in most cases fiscal legislation. In those countries where no provisions have been made for Electronic Data Interchange storage, analogy should be applied by reference to the paper. The time of storage requirements is different from country to country [or of state to state] and may vary according to the area and circumstances.
For this reason, the parties should ensure that the specified time of storage complies with any national legislation. The Uniform Rules of Conduct for Interchange of Trade Data by Tele-transmission (edited by the International Chamber of Commerce) suggest a period of storage of three years. The same duration of storage has been adopted by the fiscal legislation of some countries. Such a period should be considered as a minimum requirement to store information in an accurate and secure way. This time period of three years is suggested as the time limit to consider by parties, should there be no other legal or customary requirement.
If the requirements of national law vary compliance with the laws in question should be ensured. It must be stressed that laws of many countries require a period of storage, of 7 years or more. It must also be emphasized that such storage may need to be ensured for various purposes, including but not limited to, audit, accountancy, tax, evidence, and other administrative or legal requirements. It is recommended that careful storage of the information be ensured. The Electronic Data Interchange messages sent or received should, for the security of the transaction, be stored completely and in a chronological order, in a secure way and without alteration.
Certification of the data-log may be necessary or desirable for the purposes of introducing the data-log as evidence. More legal requirements in connection with the storage of the data may exist at national level and should be carefully followed.
10.5.10.2 Format of Storage
The data transferred using Electronic Data Interchange should be stored in the agreed format (see user manual) in which it has been sent or in the format in which it has been received.
This is the format of the data that can be considered as originally received and will constitute, if necessary, evidence of the Electronic Data Interchange message as it has been sent or received, before any translation of the message has happened.
If an Electronic Data Interchange message has been electronically signed, it will only be possible to verify it against the format in which the message has been sent.
The data should also be stored in the format in which it is translated in the information system of the receiver or from the information system of the sender. This will be however, a matter for decision of the parties. The readability of, and the possibility to print out the messages are criteria most required by national legislation and should be complied with. To ensure that readability is maintained, any material, software or any other operational equipment which may be required to access the data and read it, should be retained by the parties, even in the case where updating of systems have occurred. The parties may wish or need, in such cases, to keep the availability of such equipment without retaining it themselves. Such possibility should only be relied on after verification of national legislation requirements.
Each party should prepare a permanent copy of its data-log at a frequency that would depend on the quantity of transactions. Some regularity is desirable if the permanent record is to be admissible as evidence in legal proceedings as routinely prepared business record.
To ensure that all documents sent have been received the permanent copy of the data-log should be delivered to the other party for reconciliation purposes and a procedure for objection should be specified.
Sample Clauses
A Data-log, including any Electronic Data Interchange Message as sent and received, shall be maintained by each of the Parties without any modification for a minimum period of [insert number of] years/as specified in the User Manual, following the completion of the transmission.
Parties shall ensure that electronic or computer records of the Electronic Data Interchange Messages shall be readily accessible, are capable of being reproduced in a human readable form and of being printed, if required. Any operational equipment required in this connection shall be retained.
Each Party shall designate one or more individuals with appropriate authority as the persons responsible for the systems and procedures relating to the recording and storage of the Data-log. Any such authorized person shall be competent to certify the accuracy and completeness of the Data-log.
At the end of each period as specified in the User Manual or more frequently as a Party may wish, each Party shall prepare a permanent copy of its Data-log for the immediately preceding period. The permanent copy for that period shall be certified by one of the persons authorized pursuant to paragraph above and prepared in duplicate in an unalterable form of electronic or optical media as specified in the User Manual. If not more than [insert number] Electronic Data Interchange Messages have passed between the Parties during that period, a Party may, at its option, prepare the permanent record of the Data-log for that period in written form.
Each Party shall deliver one duplicate of its permanent Data-log to the other who shall have a period of [insert number] days following receipt to compare it with its own, and shall give notice to the other stating the details of any objections with respect to the accuracy or completeness of the record received. In the absence of any such notice of objection upon the expiry of that period the permanent record of the Data-log shall be conclusively deemed to have been accepted as accurate and complete by both Parties. Each Party may retain the other Party's Data-log for such period as it considers appropriate.
10.5.11 Operational Requirements for EDI
10.5.11.1 Operational Environment
The objective of this clause is to include in an agreement the basic requirements for operating Electronic Data Interchange. The list of operational and technical elements that are mentioned in the clause on OPERATIONAL REQUIREMENTS FOR ELECTRONIC DATA INTERCHANGE is not exhaustive. The details regarding these operational requirements will be developed in the user manual, in accordance with the clause on TECHNICAL SPECIFICATIONS AND REQUIREMENTS.
10.5.11.2 Operational Equipment
Although Electronic Data Interchange is independent from the hardware, the software and the telecommunication means, the ability to exchange Electronic Data Interchange messages requires information systems to be able to effectively receive, send and process Electronic Data Interchange messages. Basic requirements in that respect include the efficient working of the equipment used for the transfer of messages, including hardware, appropriate software, and software translation.
10.5.11.3 Means of Communications
Parties need to determine the method of transmission that they will use including, in particular, the telecommunications protocols and, where necessary, the choice of third party service providers (i.e., suppliers of Value Added Network Services), which might be used to provide a range of services. need to determine the method of transmission that they will use including, in particular, the telecommunications protocols and, where necessary, the choice of third party service providers (i.e., suppliers of Value Added Network Services), which might be used to provide a range of services.
10.5.11.4 EDI Message Standards
The appropriate specifications required to exchange Electronic Data Interchange messages need to be determined by the parties. Many standards are available. Parties should reach an agreement on these and determine also all appropriate details and specifications. The use of standards developed or accepted by the International Standardization Organization (ISO) should be encouraged.
10.5.11.5 Codes
Code lists that are used for Electronic Data Interchange are essential. Where possible the use of international standards or officially published code lists is recommended. These may not cover all the needs of the parties. In that case it is recommended, in order to promote efficiency, that preference should be given to the use of code lists which are published and maintained by known organizations and which ensure the correspondence with other coding systems (for example: statistical code lists).
Sample Clause
In order to undertake Electronic Data Interchange the Parties shall implement and maintain the operational environment that includes but is not limited to the following:
Operational Equipment. The Parties shall provide and maintain, the equipment, software, and services necessary to transmit, receive, translate, record and store Electronic Data Interchange Messages.
Means of Communication. The Parties shall determine the means of communication to be used, including the telecommunication protocols and if required, the choice of third Party service providers.
Message Definitions. The Parties shall use ISO definitions for Electronic Data Interchange Messages as defined in the User Manual.
Standards. All Electronic Data Interchange Messages defined in the User Manual shall be transmitted in accordance with standards, recommendations, and procedures as defined in the User Manual.
Codes. Data element code lists referred to in Electronic Data Interchange Messages shall include the agreed standard maintained code lists as defined in the User Manual. Where such code lists are not available, preference shall be given to the use of published and maintained code lists.
10.5.12 Technical Specifications and Requirements
10.5.12.1 User Manual
The user manual should determine all the technical requirements and specifications that are required in order to properly exchange Electronic Data Interchange messages.
Although it is not easy to provide a list of all the elements which need to be taken into account, as these will vary according to the needs of the parties, it can be emphasized that relevant specifications with regard to the following points need to be provided:
The specifications relating to the operational requirements in the clause on OPERATIONAL REQUIREMENTS FOR ELECTRONIC DATA INTERCHANGE, including:
· Specifications required in relation to software and translation software for the purpose of Electronic Data Interchange exchanges;
· Communication protocols and third party services (Value Added Network Services);
· Message standards and recommendations, including the list of messages and their references;
· The conditional elements where needed;
· The messages design guidelines;
· The implementation guidelines;
· The directories;
· The code lists;
· The reference to the documentation;
· The versions and updates;
· The methods used for storage of transmissions.
The parties should specify in the user manual:
· The method that they will use to implement updated versions of messages, rules, guidelines and directories;
· The specifications required for the processing and acknowledgment of Electronic Data Interchange messages;
· The specifications relating to security means for Electronic Data Interchange messages; and
· The specifications relating to recording and storage, the time limits.
Time limits may be of critical importance in Electronic Data Interchange, in particular when Electronic Data Interchange is combined with other techniques such as "Just-in-Time."
10.5.12.2 Test and Trial Procedures
Technical experts have made it clear that it may prove not only useful, but also sometimes necessary, to run tests to ensure the proper working of the systems and telecommunications. Practice shows that such tests are, in fact, usually conducted by parties commencing use of Electronic Data Interchange and this generally happens in two steps. Firstly, Electronic Data Interchange messages are exchanged in parallel with the paper documents and secondly, when this test is satisfactory, Electronic Data Interchange messages are exchanged without paper support. It may also be necessary to conduct further tests from time to time, for example after changes to the system have been implemented.
The parties should ensure that any data sent is free of viruses etc.
Sample Clauses
The User Manual shall include the technical, organizational, and procedural specifications and requirements to operate Electronic Data Interchange according to the terms of this Agreement, which includes but is not limited to the following:
· Operational requirements for Electronic Data Interchange, as referred to in the Clause OPERATIONAL REQUIREMENTS FOR ELECTRONIC DATA INTERCHANGE, including, operational equipment, means of communication and codes;
· Processing and acknowledgment of Electronic Data Interchange Messages;
· Security and protection of Electronic Data Interchange Messages;
· Time limits;
· Procedures for tests and trials to establish and monitor the adequacy of the technical specifications and requirements;
· Recording and storage of Electronic Data Interchange Messages.
· The Parties shall ensure that any data sent is free of viruses, etc.
Sample Annex
User Manual annexed to
Agreement
no.
dated
1. Time limits:
For processing messages after receipt:
For Acknowledgement of Receipt of the message
For rejection messages.
2. Messages which always require Acknowledgement of Receipt:
[e.g., termination of this Agreement]
3. Specific conditions regarding Acknowledgment of Receipt:
Messages concerning [...] will be acknowledged by the recipient Party within [insert number] hours but in any event before close of business for the day concerned.
4. For Electronic Mail, each Party shall include in each message it transmits: its name, the date and time of the transmissions, the reference (if any) to which it pertains, and the name and telephone number and Electronic Mail address of the individual authorized to transmit the message.
5. Alternative recovery procedure:
6. Procedures and measures to fulfill the requirements set forth in the Clauses on SECURITY AND PROTECTION OF IN CONFIDENCE INFORMATION: unauthorized access, alteration, delay, destruction, loss verification of origin, verification of integrity, non-repudiation of origin/receipt, confidentiality, time limits for report by receiver on rejection or error, Electronic Signature.
7. Confidential (NATO classification) information set forth in Clause SECURITY:
Reference can be made to C-M(55)15(Final)
On classification issues see C-M(55)15(Final) page 133 through 135)
Marking and tagging
8. Authorization for disclosure:
9. Method of encryption:
10. Archiving requirements:
Detail the technical provisions to ensure that a complete and unalterable Data-log is established and maintained
Provisions for regular exchange of Data-logs.
11. Operational requirements and technical specifications e.g.:
Equipment
Software
Third Party Services
Communication services
Communication Protocols
Message standards, directories, versions, syntax, type of messages, segments, and data elements
Codes
Procedure for tests and trials
Availability
12. Modification:
Any modification to this User Manual shall be -agreed in writing between the Parties in accordance with the Clause on EFFECT, MODIFICATIONS, TERMINATION AND SEVERABILITY.
10.5.13 Liability
Where liability stems from an underlying contract, the terms of that contract should prevail over the provisions of the Electronic Data Interchange agreement.
10.5.13.1 Exclusion of Liability
The principle is that parties to an agreement should be held responsible for their acts and omissions. In addition, the risks should be born by the party responsible according to the law applicable. However, parties might want to limit (by introducing a maximum amount) or exclude liabilities. In this clause special, incidental, indirect, or consequential damages liability in connection with the agreement have been excluded.
10.5.13.2 Force Majeure
An exception to liability is made in the case of what is commonly known as "Force Majeure." The concept of force majeure included in this clause is in line with the concept developed by the United Nations Convention on Contracts for the International Sale of Goods or Vienna Convention of 11 April 1980, and, in the absence of uniform national law on this point, provides a definition which the parties may expand, if they wish, by citing various situations in which liability may be exempted.
10.5.13.3 Intermediaries Liability
The parties might use a third party (also called Value Added Network Services) to provide services such as logging, or encryption. Liability for the actions of a third party is included in many agreements and generally accepted since often the third party will effectively be acting as an agent of the user. Moreover, it is the party who will use the service of a third party provider and who has the contractual relationship with the service provider who will be in the best position to sue the service provider in the case where its liability could be engaged. A clause to that extend could be introduced here.
Where one party imposes the use of a particular intermediary on the other, it seems fair that the party who imposes such use should be responsible for damages which result from using that intermediary instead of the one who has to make use of it.
10.5.13.4 Supplier Contracts
The Electronic Data Interchange agreement fits within a complex of relations enabling the Electronic Data Interchange involving many parties, such as a Telephone Company or a supplier of Value Added Network Services. Contracts with these suppliers, not chosen or imposed by either party to the Electronic Data Interchange agreement might exclude liabilities.
Sample Clauses
This clause shall not apply in cases where Parties have agreed on an underlying contract and the liability results from such contract.
Except for willful misconduct or gross negligence, no Party to this Agreement shall be liable for any special, incidental, indirect or consequential damages caused by a failure to perform its obligations under this Agreement. Except for willful misconduct or gross negligence, liability for any direct damages incurred is limited to the maximum amount of [insert amount and currency].
No Party to this Agreement shall be liable for any loss or damage suffered by the other Party caused by any delay or failure to perform in accordance with the provisions of this Agreement, where such delay or failure is caused by an impediment beyond that Party's control and which could not reasonably be expected to be taken into account at the time of conclusion of the Agreement or the consequences of which could not be avoided or overcome. This provision shall not relieve liability for any matter that constitutes a breach of the Clauses on SECURITY OR PROTECTION OF IN CONFIDENCE INFORMATION.
If a Party requires another Party to use the services of an intermediary to perform the transmission, logging or processing of an Electronic Data Interchange Message, the Party who required such use shall be liable to the other Party for damage arising directly from that intermediary's acts, failures, or omissions in the provision of said services.
10.5.14.1 Options
In case of disputes resulting from the performance of underlying contracts, the dispute provisions of such contracts should prevail.
Three dispute resolution options are offered:
1. The first option provides a clause on arbitration.
2. The second option provides a jurisdiction clause, where the choice of a jurisdiction is to be agreed in the case where the parties decide that dispute will be referred to court.
3. A third option leaves open the choice between arbitration and court of law.
It should perhaps be emphasized that because of the relationships that Electronic Data Interchange creates between users there is a great potential for dispute to be resolved by negotiation. It is only when such negotiations fail that the clauses on dispute resolution will become effective and useful.
10.5.14.2 Arbitration Clause
Parties may wish to decide to resolve their dispute by way of arbitration. Arbitration may prove a practical procedure to resolve a dispute involving parties of different countries. It offers the advantage of the choice of arbitrator(s) or of the appointing authority and of a more speedy procedure although this is not always the rule. It can be attractive for the confidentiality of the procedure, which is sometimes favored by parties. The arbitration award is in principle final although appeal is possible.
Many countries still require a written and clear statement on arbitration when this is the choice of dispute resolution and the parties are therefore advised to include such clause.
The clause offered for inclusion in the agreement under option A refers to the rules of conciliation and arbitration of the International Chamber of Commerce. The parties need to define how the arbitrator will be nominated. A choice can be made between one or three person(s) nominated by agreement or in case of failure of an agreement on the arbitrator(s), an appointing authority can proceed to the nomination. The parties should therefore indicate which will be the appointing authority. In addition, it can be determined by parties in which language the arbitration procedure should be conducted.
10.5.14.3 Court of Law
In the case the parties intend to have their litigation solved by a court, the second alternative provision provides for the parties to choose the competent court and stipulate it in their agreement. In the case where the parties do no make such a choice, the competent court shall be determined by reference to e.g., the Convention on jurisdiction and the enforcement of judgments in civil and commercial matters.
10.5.14.4 0ption C
If parties do not want to exclude up front one of the methods of dispute resolution this option can be selected.
Sample Clauses
In case of disputes resulting from performance of underlying contracts, the dispute provision of such contract shall apply.
Option A: Arbitration.
Any disputes between the Parties arising from or relating to this agreement shall be finally settled in accordance with the conciliation and arbitration of regulations of the International Chamber of Commerce, by one or more arbitrators appointed in pursuance of these regulations and there shall be no right of appeal nor recourse of any kind.
Option B: Court of Law.
Any dispute arising out of or in connection with this Agreement shall be referred to the competent Court of [insert name of country], which shall have sole jurisdiction.
Option C: Arbitration or Court of law.
Unless the Parties agree in writing to submit the matter to arbitration or other procedure for the resolution of dispute, or to select a different jurisdiction any matter or dispute arising from, out of or in connection with this Agreement as to its validity, interpretation, construction or performance shall be subject to sole and exclusive jurisdiction of the [insert name of country] Court.
10.5.15 Applicable Law
The parties to the agreement should indicate their choice of applicable law
Sample Clause
This Agreement is governed by the Law of [insert name of country].
10.5.16 Effect, Modification, Term, and Severability
10.5.16.1 Effect
This article states that the agreement does not come into effect until the parties sign it.
10.5.16.2 Modification
Any modification, addition, or alternative provisions to the agreement should only be made in writing and agreed by all parties.
10.5.16.3 Termination
The period of one month proposed in this clause regarding termination notice may be extended by the parties. It is not advised to reduce it as it is considered as a minimum.
The Termination Clause provides that some rights and obligations relating to the agreement are of fundamental importance and should remain in effect following termination of the agreement.
10.5.16.4 Severability
A paragraph should be inserted to prevent a party from terminating the agreement simply because one clause has become invalid. It is also intended to prevent parties from terminating an agreement to avoid certain obligations
Sample Clauses
Effect. The Agreement shall be effective from the date on which it is signed by the Parties.
Modification. Where required, additional or alternative provisions to the Agreement including modification to the User Manual, agreed in writing by the Parties, will be considered as part of the Agreement upon the signature on behalf of the Parties by the original signatories or their authorized representatives.
Termination. Any Party may terminate the Agreement by giving not less than ...[one] month's notice either by registered post or by any other means (e.g., by an Electronic Data Interchange Message) agreed between the Parties. Termination of the Agreement shall only affect Electronic Data Interchange (including Electronic Mail) transactions after that date. Notwithstanding termination for any reason, the rights and obligations of the Parties referred to in Clauses ADMISSIBILITY IN EVIDENCE OF ELECTRONIC DATA INTERCHANGE MESSAGES, SECURITY, PROTECTION OF IN- CONFIDENCE INFORMATION, DATA-LOG RECORDING AND STORAGE AND RECONCILIATION OF ELECTRONIC DATA INTERCHANGE MESSAGES, DISPUTE RESOLUTION and APPLICABLE LAW shall remain in effect.
Severability. Should any clause or part of a clause of the Agreement be deemed invalid, all other clauses shall remain in full force and effect [and the Parties shall agree on a substitute provision]. All annexes to this Agreement shall be an integral part of the Agreement.
10.5.17 Signature Page
Sample Clause
For the Minister of Defense For [insert company name]
of [insert name of country]
or for NATO agency
[insert name] [insert name]
[insert title] [insert title]
date date
place place
