DATA EXCHANGE STANDARDS FOR REGISTRY SYSTEMS UNDER THE KYOTO PROTOCOL. FUNCTIONAL SPECIFICATIONS (Version 1.0) Non-paper.

Transcription

1 DATA EXCHANGE STANDARDS FOR REGISTRY SYSTEMS UNDER THE KYOTO PROTOCOL FUNCTIONAL SPECIFICATIONS (Version 1.0) Non-paper 21 November 2003

2 CONTENTS 1. INTRODUCTION Purpose Intended audience Scope Definitions, acronyms and abbreviations ASSUMPTIONS GENERAL CONSTRAINTS EXCHANGE MECHANISM Functional requirements Message transport Transaction sequences Reconciliation sequences TRANSFER FORMAT Functional requirements Transaction-related attributes Reconciliation-related attributes Attributes relating to messages Attributes relating to registry systems Identifier contents and formats Non-functional requirements DATA LOGGING Functional requirements Non-functional requirements...23 Data Exchange Standards, Functional Specifications, Version <1.0> Page 2 of 41

3 7. OPERATIONS MANAGEMENT Functional requirements Publication of information by the transaction log Non-functional requirements Validity Performance Safety CHANGE MANAGEMENT...27 ANNEX A ANNEX B GLOSSARY OF TERMS...28 TRANSACTION PROCESSES...31 Data Exchange Standards, Functional Specifications, Version <1.0> Page 3 of 41

4 Functional Specifications 1. Introduction 1.1 Purpose These functional specifications contain the key requirements mandated by the data exchange standards for registries and the transaction log under the Kyoto Protocol. They build upon the general design requirements of the standards, as adopted by the Conference of the Parties. The functional specifications are to be further elaborated by preparing technical specifications of the data exchange standards. Whereas the functional specifications set out what needs to be done in registries and the transaction log, the technical specifications will detail how these need to be implemented. The technical specifications are to ensure that the data exchange standards are implemented in all registries and the transaction log in a compatible manner. With this in mind, these functional specifications set out constraints within which the technical specifications must remain and, where greater discretion is possible, acceptance criteria to guide the development of the technical specifications. 1.2 Intended audience 1.3 Scope This document is to guide technical experts in preparing the technical specifications. The data exchange standards define how data is to be exchanged between national registries, the CDM registry and the transaction log (known generically as registry systems ) under the Kyoto Protocol. The standards therefore relate to sequences of messages and the data protocols and formats to be used in the data exchange (the arrows below), as well as requirements that registries and transaction log need to fulfil. National registry (of an Annex I Party) CDM registry (Non-Annex I Party) Sender/receiver Communication via the data exchange standards Sender/receiver Sender/receiver Communication hub Autochecks Transaction log Data Exchange Standards, Functional Specifications, Version <1.0> Page 4 of 41

5 This functional specification includes: Section 2 Section 3 Section 4 Section 5 Section 6 Section 7 Section 8 Annex A Annex B Assumptions Facts held to be true for the functional specifications to be valid General constraints General boundaries that the system must stay within Exchange mechanism Standards sequences of messages and their manner of transmission Transfer format Requirements for how to format of data contained in messages Data logging Requirements for data that is to be recorded in registries and the transaction log Operational management Requirements for the publication of information by the transaction log and for data accuracy, data integrity, data processing, system testing, and security Change management Manner in which the data exchange standards may be changed over time Glossary of terms Definitions, acronyms and abbreviations Interaction processes Processes of interaction among registries and the transaction log 1.4 Definitions, acronyms and abbreviations See the glossary in annex A for definitions, acronyms and abbreviations. Note in particular that the term registries refers to both national registries and the CDM registry. Registry systems refers to both registries and the transaction log. 1.5 These specifications are derived from decisions by the Conference of the Parties: Decision 19/CP.7 On modalities for accounting for assigned amount (including requirements for national registries and the transaction log in section II of the annex) document FCCC/CP/2001/13/Add.2 Appendix D to the annex of decision 17/CP.7 On the CDM registry requirements, see document FCCC/CP/2001/13/Add.2 Decision 24/CP.8 On the general design requirements of the data exchange standards document FCCC/CP/2002/7/Add.3 Informal paper by the chair of the inter-sessional consultations on possible data exchange standards document FCCC/SBSTA/2002/INF.20 Decisions 15-18/CP.7 On emissions trading and projects under the clean development mechanism and joint implementation document FCCC/CP/2001/13/Add. 2 Data Exchange Standards, Functional Specifications, Version <1.0> Page 5 of 41

6 2. Assumptions These functional specifications have been developed on the basis of the following assumptions. A1 Assumption The decisions contained in the derivation documents will remain stable 3. General These general constraints represent design decisions that have been mandated for the data exchange standard and shall be adhered to. Single holding of unit DES-C1 Decision 19/CP.7, para 20 Decision 17/CP.7, appendix D, para 4 Each unit shall be held in only one account at a given time Industry standards DES-C2 Decision 24/CP.8, paras 5h, 8 If an international or industry standard meets the requirements, it shall be used in preference to an internal standard being developed Platform and software independence DES-C3 Decision 24/CP.8, paras 5h, 8 The data exchange standard shall not be bound to a platform, software or software vendor Independent design of registry systems DES-C4 Decision 24/CP.8, paras 5h, 8 The data exchange standard shall not unnecessarily constrain the design or operation of the registries or the transaction log Universal time DES-C5 - All date and time certification shall be in universal time Data Exchange Standards, Functional Specifications, Version <1.0> Page 6 of 41

7 4. Exchange mechanism 4.1 Functional requirements Message transport Sender/receiver module DES-EM1 Decision 24/CP.8, para 6 Registry systems shall be able to send data to other registry systems and receive data from other registry systems All messages shall be routed through the central communications hub integrated with the transaction log Buffering of messages shall be supported, on a first-in first-out basis Acceptance criteria Communications protocol DES-EM2 Decision 24/CP.8, paras 7h, 7i Registry systems shall send and receive all messages using a specified communications protocol The protocol shall use a reliable data stream All messages shall be acknowledged Sender shall be notified in event of errors Use Web Services Data transfer format DES-EM3 Decision 24/CP.8, paras 6, 8, 9 Acceptance criteria Registry systems shall send and receive all messages using a specified data transfer format Format shall support structured data storage Use XML Secure transmission DES-EM4 Decision 24/CP.8, para 5f Registry systems shall send and receive all messages using secure connections Data Exchange Standards, Functional Specifications, Version <1.0> Page 7 of 41

8 Authentication DES-EM5 Decision 24/CP.8, para 20b Registry systems shall be uniquely and securely identified and identifiable using authentication information Authentication information for each registry system shall be unique throughout the transaction log, national registries and the CDM registry Specific authentication information shall be defined by the transaction log Encryption DES-EM6 Decision 24/CP.8, para 20a Registry systems shall encrypt data before transmission to another system using a specified type and level of encryption Shall use at least 128 bit encryption Data Exchange Standards, Functional Specifications, Version <1.0> Page 8 of 41

9 4.1.2 Transaction sequences Transaction sequences DES-EM7 Decision 19/CP.7, paras Decision 24/CP.8, paras 6, 7g, 11, 12, 18 Acceptance criteria Registry systems shall carry out transactions through data exchange defined by standard sequences of messages Sequences shall include: Issuance of AAUs, RMUs and CERs Conversion of AAUs and RMUs to ERUs External transfer of AAUs, RMUs. ERUs and CERs to another registry Internal transfer of AAUs, RMUs, ERUs and CERs to a cancellation or retirement account Carry over of AAUs, ERUs and CERs to the next commitment period Sequences shall define, at minimum, for each message: Order in the sequence Purpose Transferring registry system Receiving registry system Content Response times Point at which the transaction is deemed unequivocally final Content shall include data defined by the data transfer format, as appropriate for each sequence The carry-over sequence shall be followed by the cancellation of units not carried over from the previous commitment period All messages shall be routed through the central communications hub integrated with the transaction log Discrepancy information shall be included in messages transmitted subsequent to the discrepancy being discovered Sequences are consistent with the transaction processes contained in Annex B Transaction priority DES-EM8 Decision 24/CP.8, para 13 Units subject to an initial transaction shall not be processed as part of a further transaction until the initial transaction is completed, terminated or cancelled Data Exchange Standards, Functional Specifications, Version <1.0> Page 9 of 41

10 Constraint Transaction termination DES-EM9 Decision 19/CP.7, para 43a Decision 24/CP.8, para 7g Upon notification of a discrepancy by the transaction log, affected registries shall terminate the affected transaction The initiating registry shall terminate the affected transaction in the first instance The acquiring registry, where relevant, shall be able to terminate an affected transaction where it has not previously been terminated Transactions shall be terminated as a whole and not in part Transaction cancellation DES-EM10 Decision 24/CP.8, para 12 Constraint In the event of a specified response time having elapsed without a response to a message, the transaction log shall cancel the affected transaction Response times shall be specified Transactions shall be cancelled as a whole and not in part Data Exchange Standards, Functional Specifications, Version <1.0> Page 10 of 41

11 4.1.3 Reconciliation sequences Reconciliation sequences DES-EM11 Decision 24/CP.8, paras 6, 18, 26 Registry systems shall carry out reconciliation through data exchange defined by a standard sequence of messages Reconciliation shall take place on the basis of a data snapshot for a common specified time The sequence shall define, at minimum, for each message: Order in the sequence Purpose Transferring registry system Receiving registry system Content Reconciliation occurs through registries providing data to the transaction log; the transaction log compares the data with its own records and identifies any inconsistencies between the data sets Reconciliation can occur a maximum of once every 24 hours Reconciliation may proceed on three levels: Total units, by unit type and unit status, in aggregate of all holding accounts, in aggregate of all cancellation accounts, and in the retirement account Serial numbers of unit detail in respective aggregates Transaction detail and other audit information Content shall include data defined by the data transfer format All messages shall be routed through the central communications hub integrated with the transaction log Transa ction prevention DES-EM12 Decision 24/CP.8, paras 25e, 26 Registries shall prevent transactions involving units for which an inconsistency has been discovered through the reconciliation process, until that inconsistency is resolved Registries shall terminate current transactions involving affected units Registries shall prevent the initiation of transactions involving affected units until the inconsistency is resolved Data Exchange Standards, Functional Specifications, Version <1.0> Page 11 of 41

12 Administrator manual influence DES-EM13 Decision 24/CP.8, paras 20c, 26 Acceptance criteria Where an inconsistency is discovered through a reconciliation action, the administrators of the affected registry systems shall, as appropriate and in consultation with the administrator of the other registry system, manually adjust unit holdings information in order to correct the inconsistency and inform the other administrator of the manual adjustments made Inconsistency information shall be examinable Data which may be manually adjusted by the registry administrator within the registry shall include: Units holdings data Serial numbers Manual adjustments shall be automatically listed and shall be available for audit purposes The transaction log shall notify the affected registry and the secretariat of inconsistencies remaining unresolved beyond a specified period of time Data maintained by the transaction log represents a single, full and final record of unit holdings and transactions Data Exchange Standards, Functional Specifications, Version <1.0> Page 12 of 41

13 5. Transfer Format 5.1 Functional requirements Transaction-related attributes Transaction number DES-TF1 Decision 19/CP.7, para 41a Decision 24/CP.8, para 7c The data transfer format shall incorporate the transaction number Shall use an attribute Transaction type DES-TF2 Decision 19/CP.7, para 41b Decision 24/CP.8, paras 6, 7b The data transfer format shall incorporate the type of transaction Shall use an attribute Transaction types shall include: Issuance of unit (initial creation of a unit) Conversion of unit (transformation to create an ERU) External transfer of units (between registries) Cancellation of unit (internal transfer) Retirement of unit (internal transfer) Carry-over of unit (extension of validity) Record set DES-TF3 Decision 19/CP.7, para 41b Decision 24/CP.8, para 7d The data transfer format shall incorporate the record set of information to be associated with each transaction Shall use attributes The record set shall include: Total quantity of units involved Serial numbers of units involved Account number of the activity or source account Account number of the destination account, where applicable Data Exchange Standards, Functional Specifications, Version <1.0> Page 13 of 41

14 Transaction status DES-TF4 Decision 24/CP.8, para 7e The data transfer format shall incorporate the status of a transaction Shall use an attribute Transaction states shall include: Proposed Checked (no discrepancy) Checked (discrepancy) Accepted Completed Terminated Cancelled Rejected Discrepancy information DES-TF5 Decision 24/CP.8, paras 7f, 15 The data transfer format shall incorporate discrepancy information Shall use attributes Discrepancy information shall include: Serial numbers of affected units Rules against which there is a discrepancy Reconciliation-related attributes Reconciliation number DES-TF6 Decision 24/CP.8, paras 7c The data transfer format shall incorporate the reconciliation number Shall use an attribute Action type DES-TF7 Decision 24/CP.8, paras 6, 7b The data transfer format shall incorporate the type of action Shall use an attribute Shall identify the action as a reconciliation action Data Exchange Standards, Functional Specifications, Version <1.0> Page 14 of 41

15 Record set DES-TF8 Decision 24/CP.8, para 26 Acceptance criteria The data transfer format shall incorporate unit holdings information (for registries to transmit data to the transaction log) Reconciliation data shall include, as requested by the transaction log: Total units, by unit type and unit status, in aggregate of all holding accounts, in aggregate of all cancellation accounts, and in the retirement account Serial numbers of unit detail in respective aggregates Transaction detail and other audit information Shall use attributes Reconciliation stage DES-TF9 Decision 24/CP.8, para 7b The data transfer format shall incorporate the stage reached within a reconciliation sequence Shall use an attribute Shall conform to the exchange mechanism Reconciliation status DES-TF10 Decision 24/CP.8, para 7e The data transfer format shall incorporate the status of a reconciliation action Shall use an attribute Reconciliation states shall include: Initiated Completed Total inconsistent Unit inconsistent Inconsistency information DES-TF11 Decision 24/CP.8, para 26 The data transfer format shall incorporate inconsistency information (for the transaction log to inform registries of inconsistencies discovered) Shall use attributes Inconsistency information shall include: Serial numbers of affected units Transaction details and other auditing information Data Exchange Standards, Functional Specifications, Version <1.0> Page 15 of 41

16 Acceptance criteria Manual influence information DES-TF12 Decision 24/CP.8, para 20c The data transfer format shall incorporate information on manual adjustments undertaken by the administrator (for the transaction log and registries to inform each other of actions taken) Information shall include manual adjustments made to: Unit holdings data Serial numbers Use attributes Time certification information DES-TF13 Decision 24/CP.8, para 7a The data transfer format shall incorporate the date and time at which the data snapshot shall be taken Shall use an attribute Attributes relating to messages Message identifier DES-TF14 Decision 24/CP.8, para 7b The data transfer format shall incorporate a unique identifier for each message Shall use an attribute Each identifier shall be unique throughout the transaction log, national registries and the CDM registry Purpose DES-TF15 - The data transfer format shall incorporate the purpose of each message Shall use an attribute Information shall conform to the purpose information defined in the exchange mechanism Data Exchange Standards, Functional Specifications, Version <1.0> Page 16 of 41

17 Time certification information DES-TF16 Decision 24/CP.8, para 7a The data transfer format shall incorporate the time stamp identifying the time at which the message is received or sent by the transaction log Attributes relating to registry systems Authentication information DES-TF17 Decision 24/CP.8, para 20b The data transfer format shall incorporate authentication information of the registry or transaction log transmitting the message Information shall ensure that: Each registry system is uniquely and securely identified Each registry system may identify other registry systems Authentication information for each registry system shall be unique throughout the transaction log, national registries and the CDM registry Specific authentication information shall be defined by the transaction log Destination registry system DES-TF18 - The data transfer format shall incorporate information on the destination registry system Shall use an attribute Data Exchange Standards, Functional Specifications, Version <1.0> Page 17 of 41

18 5.1.5 Identifier contents and formats Serial number format DES-TF19 Decision 17/CP.7, appendix D, para 7 Decision 19/CP.7, paras 24, 27, 29 Decision 24/CP.8, para 14 Each unit shall have a unique serial number (assigned by the registry of the originating Party) conforming to a specified format Each serial number shall be unique throughout the transaction log, national registries and the CDM registry Serial numbers shall not be modified, except for changes in the unit type indicator and the addition of a project identifier during conversion of AAUs and RMUs to ERUs Units carried over to a next commitment period shall maintain their original serial numbers The originating Party identifier shall use the 2 letter country code (ISO3166) Serial numbers shall consist of at least the following elements: Element AAU RMU CER ERU Originating Party YES YES YES YES Unit type YES YES YES YES Unique number YES YES YES YES Original commitment period Applicable commitment period YES YES YES YES YES YES YES YES LULUCF activity NO YES YES YES Project NO NO YES YES Track 1 or 2 NO NO NO YES The LULUCF activity element shall distinguish: Category 1: Afforestation, reforestation and deforestation activities (Note: these activities are included under Article 3.3 of the Protocol; all LULUCF activities under the CDM for the first commitment period will be in this category) Category 2: Forest management activities (Note: these activites are included under Article 3.4 of the Protocol) Category 3: Cropland management, grazing land management and revegetation (Note: these activities are included under Article 3.4 of the Protocol) Acceptance criteria One consistent format is to be used for serial numbers of all units Size of data transmission is not to be greater than necessary; data processing is to be efficient Data Exchange Standards, Functional Specifications, Version <1.0> Page 18 of 41

19 Account number format DES-TF20 Decision 17/CP.1, appendix D, para 5 Decision 19/CP.7, para 22 Decision 24/CP.8, para 16 Each account in a registry shall have a unique account number (assigned by the registry of the Party) conforming to a specified format Each account number shall be unique throughout the transaction log, national registries and the CDM registry Account numbers shall consist of at least the following elements: Element Holding Account Cancellation Account Retirement Account Party identifier YES YES YES Commitment Period NO YES YES Account Type YES YES YES Unique number YES YES YES The Party identifier shall use the 2 letter country code (ISO3166) The account type element shall distinguish, at minimum, holdings accounts, cancellation accounts, retirement accounts Acceptance criteria One consistent format is to be used for all account numbers Transaction number format DES-TF21 Decision 19/CP.7, para 41a Decision 24/CP.8, para 17 Each transaction shall have a unique transaction number (assigned by the registry of the initiating Party) conforming to a specifi ed format Each transaction number shall be unique throughout the transaction log, national registries and the CDM registry Transaction numbers shall not be modified once they are assigned Transaction numbers shall consist of at least the following elements: Initiating Party identifier Commitment period Unique number The initiating Party identifier shall use the 2 letter country code (ISO3166) Data Exchange Standards, Functional Specifications, Version <1.0> Page 19 of 41

20 Project number format DES-TF22 Decision 19/CP.7, para 41a Decision 24/CP.8, para 17 Each project shall have a unique project number (assigned by the registry of the initiating Party) conforming to a specified format Each project number shall be unique within the originating registry Project numbers shall not be modified once they are assigned Project numbers shall consist of at least the following elements: Party hosting the project Unique number Activity The originating Party identifier shall use the 2 letter country code (ISO3166) The activity element shall distinguish: Category 1: Removals through afforestation, reforestation and deforestation activities Category 2: Removals through forest management activities Category 3: Removals through cropland management, grazing land management and revegetation Category 4: Emission reductions Reconciliation number format DES-TF23 Decision 24/CP.8, para 26 Each reconciliation action shall have a unique reconciliation number (assigned by the transaction log) conforming a specified format Each reconciliation number shall be unique throughout the transaction log, national registries and the CDM registry Reconciliation numbers shall not be modified once they are assigned Reconciliation numbers shall consist of at least the following elements: Party identifier Unique number The Party identifier shall use the 2 letter country code (ISO3166) 5.2 Non-functional requirements Language support DES-TF24 Decision 24/CP.8, para 9 The data transfer format shall support multiple languages The character set in use shall support non-roman characters The character set used shall function on any operating system Data Exchange Standards, Functional Specifications, Version <1.0> Page 20 of 41

21 6. Data Logging 6.1 Functional requirements Logging transactions DES-DL1 Decision 24/CP.8, paras 5c, 20e Registries and the transaction log, including the communications hub, shall log information on transactions Logged information shall include, for each transaction: Transaction number Transaction type Record set Final transaction status Time certification for initiation of the transaction Time certification of final transaction status being reached Information on unresolved discrepancies Additions to units holdings Subtractions from units holdings Modifications to serial numbers (conversion transaction) Carry over of units to next commitment period Logged information shall be available for audit purposes Logging messages DES-DL2 Decision 24/CP.8, paras 5c, 20e Registries and the transaction log, including the communications hub, shall log information on messages Logged information shall include, for each message: Identifier Content Time certification of transmission or receipt Logged information shall be available for audit purposes Data Exchange Standards, Functional Specifications, Version <1.0> Page 21 of 41

22 Logging registry interactions DES-DL3 Decision 24/CP.8, paras 5c, 20e, 25a, 25e, 25b, 25c Registries and the transaction log, including the communications hub, shall log information on interactions with the system Logged information shall include: Users interacting with the registry Other registry systems interacting with the registry Time certification of interaction Data input by users Data input based on messages received from other registry systems Logged information shall be available for audit purposes Logging reconciliation data DES-DL4 Decision 24/CP.8, paras 5c, 26 Registries and the transaction log, including the communications hub, shall log reconciliation data Inconsistency information shall be logged and shall be available for audit purposes Message storage DES-DL5 Decision 24/CP.8, paras 5c, 20e Registry systems shall store all messages and their contents in their original form Data Exchange Standards, Functional Specifications, Version <1.0> Page 22 of 41

23 6.2 Non-functional requirements Record retention DES-DL6 Decision 24/CP.8, paras 5c, 27 Registries and the transaction log, including the communications hub, shall retain their logged records Retained records shall include: Logged transactions Logged messages Logged account information Logged registry interactions Stored messages Records for a commitment period shall be retained, at minimum, until: After the additional period for fulfilling commitments relating to the commitment period After any questions of implementation relating the commitment period have been resolved Data Exchange Standards, Functional Specifications, Version <1.0> Page 23 of 41

24 7. Operations Management 7.1 Functional requirements Publication of information by the transaction log Acceptance criteria Publication of discrepancy rules DES-OM1 Decision 24/CP.8, para 25f The transaction log shall ensure the transparency of the rules it uses to detect discrepancies Changes in the discrepancy rules shall be made available, at the latest, immediately upon the change taking effect Information is publicly accessible on the internet Acceptance Criteria Publication of discrepancy information DES-OM2 Decision 19/CP.7, para 43a Decision 24/CP.8, paras 5c, 5d, 23 The transaction log shall ensure the transparency of information relating to discrepancies it has discovered Information shall include: Serial numbers of affected units Rules against which there is a discrepancy Registries in which the units are held Transaction numbers of the affected transactions Date and time of the change in transaction status to checked (discrepancy) Current transaction status Upon notification of the discrepancy to the affected registries, the transaction log shall: Make information publicly available Forward the information to the secretariat Information shall remain available until the discrepancy is resolved Information is publicly accessible on the internet Data Exchange Standards, Functional Specifications, Version <1.0> Page 24 of 41

25 Acceptance Criteria Publication of transaction information DES-OM3 Decision 19/CP.7, para 43d Decision 24/CP.8, paras 5c, 5d The transaction log shall ensure the transparency of information relating to transactions Information shall include: Logged transaction information Total unit holdings in all holding accounts for each Party, by status Total unit holdings in all cancellation accounts for each Annex I Party, by status Total unit holdings in the retirement account for each Annex I Party Information is publicly accessible on the internet Information is updated on completion of the daily reconciliation action 7.2 Non-functional requirements Validity Acceptance criteria Accuracy of data DES-OM4 Decision 24/CP.8, paras 5b, 25a, 25d, 25e Registry systems shall ensure the accuracy of their data and data transfer Procedures and checks in place to discover inaccuracies Acceptance criteria Integrity of data DES-OM5 Decision 24/CP.8, paras 5f, 20d Registry systems shall ensure the integrity of their data and data transfer Procedures and checks in place to prevent unauthorized data modification Constraint Acceptance criteria Discrepancy prevention DES-OM6 Decision 24/CP.8, para 25f Registries shall prevent discrepancies from occurring Registries shall terminate transactions where it discovers a discrepancy Procedures and checks are in place to discover discrepancies against discrepancy rules defined by the transaction log Data Exchange Standards, Functional Specifications, Version <1.0> Page 25 of 41

26 7.2.2 Performance Efficient processing DES-OM7 Decision 24/CP.8, para 5e Registry systems shall ensure the efficient processing of data System testing DES-OM8 Decision 24/CP.8, paras 19, 24 Acceptance Criteria Registry systems shall test systems before operation, including in relation to the interaction with the communications hub All registry systems shall use common protocols and procedures for testing, initiation and suspension Disruption of operations shall be minimized Scheduled downtime DES-OM9 Decision 24/CP.8, paras 5g, 22, 24 Acceptance criteria Registry systems shall keep scheduled downtime to a minimum System testing shall be possible with minimal disruption of operations Problems are isolated so that components may be fixed individually Safety Authorization DES-OM10 Decision 24/CP.8, paras 5f, 20b, 25 b Registry systems shall protect data from unauthorized access Registries shall use authentication information defined by the transaction log Acceptance Criteria Viruses, hackers and denial of service attacks DES-OM11 Decision 24/CP.8, paras 5f, 25c Registry systems shall protect data against exposure to security compromises Action plan in place Alarm and notification mechanism in place Data Exchange Standards, Functional Specifications, Version <1.0> Page 26 of 41

27 Robust systems TL-OM12 Decision 24/CP.8, paras 5g, 25d Registry systems shall be robust Procedures shall be in place for: Safeguarding data Recovering data Recovering registry service Maintaining and restoring communications 8. Change management Change management DES-CM1 Decision 24/CP.8, para 9 Acceptance Criteria In the event of necessary changes to the technical specifications of the data exchange standards, old versions shall remain valid and identifiable until administrators have had sufficient time to implement new versions New versions shall be compatible with old versions Old version(s) remain valid for a specified period (to be defined) Data Exchange Standards, Functional Specifications, Version <1.0> Page 27 of 41

28 Annex A Glossary of terms AAU Account Accuracy Administrator Annex I Party Article Attribute Audit Authentication Authorization CER CDM CDM Executive Board CDM registry Commitment period Communications hub Communications protocol Conference of the Parties (COP) Customisation Denial of service Attack Discrepancy Downtime Assigned amount units. These are tradable units derived from an Annex I Party s emissions target under the Kyoto Protocol. They may be counted by Annex I Parties towards compliance with their emissions target and are equal to one tonne of carbon dioxide equivalent gases. An account is used to partition a registry and can hold units. There are three accounts types: holding account, cancellation account and retirement account. Condition in which information is not modified randomly by the software system. A role to configure and maintain a software system. Configuration can range from system set-up to amending data and parameters within the system. A Party to the UNFCCC listed in Annex I to the UNFCCC. These are industrialized countries, including those with economies in transition. An Article of the Kyoto Protocol. Identifier for a piece of information. Checking of recorded data. The process to confirm the identity of a user. The process to verify a permission to do something. Certified Emission Reductions. These are tradable units generated by projects in non-annex I Parties under the CDM. They may be counted by Annex I Parties towards compliance with their emissions target and are equal to one tonne of carbon dioxide equivalent gases. Clean Development Mechanism under Article 12 of the Kyoto Protocol. Projects in developing countries under the CDM result in reduced emissions, or enhanced removals, in a host non-annex I Party and generate CERs. The board supervising the CDM. It is serviced by the secretariat. The registry established by the CDM Executive Board on behalf of non-annex I Parties hosting CDM projects. It is to ensure the accurate accounting of transactions of CERs by those Parties. A specified period in which an Annex I Party is to show it compliance with its emissions target. The first commitment period is from 2008 to The central communication component integrated in the transaction log, through which all registries and the transaction log communicate. Formal rules describing how to transmit data. The supreme decision-making body under the UNFCCC. Attended by delegations from all state Parties to the UNFCCC. COP9 will be held in Milan, Italy, from 1-12 December Configuration of systems toward specific user needs within certain boundaries. A very high number of requests in very short period aimed at a software system with the goal of achieving an overload and crash of that software system. An instance of non-conformity with agreed rules for transactions. The purpose of the transaction log is to identify discrepancies in transaction proposals. The time in which a soft ware system is not available for use. Data Exchange Standards, Functional Specifications, Version <1.0> Page 28 of 41

29 Emissions trading Encryption Entities ERU Exchange mechanism Functional requirement Inconsistency Integrity Joint Implementation Kyoto mechanism Kyoto Protocol Logging Message National Registry Non-Annex I Party Non-functional requirement Party Question of Implementation Reconciliation Recovery Registry Registry system Release Process Removal The trading of units which may count towards compliance by Annex I Parties with their emissions targets. Emissions trading is provided for under Article 17 of the Kyoto Protocol. Domestic (e.g. UK) and regional (e.g. EU) emissions trading schemes are also being established. A way of protecting data from unauthorized access. Legal entities authorized by a government to participate in emissions trading or joint implementation projects. Private and/or public entities involved in the CDM. Such entities may be from public, private or non-governmental sectors. Emission reduction units. These are tradable units generated by projects in Annex I Parties under joint implementation. They may be counted by Annex I Parties towards compliance with their emissions target and are equal to one tonne of carbon dioxide equivalent gases. System for exchanging data. Requirement for which the quality test result is binary (e.g. yes/no or right/wrong) A difference found through a comparison of at least two different data sets. Data cannot be modified by any party not authorized to do so. Joint implementation under Article 6 of the Kyoto Protocol. Projects in industrialized countries under JI result in reduced emissions, or enhanced removals, in a host non-annex I Party and generate CERs. The three flexibility mechanisms established by the Kyoto Protocol: Joint implementation projects under Article 6, clean development projects under Article 12 and emissions trading under Article 17. Allied agreement to the UNFCCC containing emission reduction targets for Annex I Parties. Functionality of a software system that stores information on the system for auditing and tracking. Electronic transmission of data. A registry established by an Annex I Party. A Party to the UNFCCC which is not listed in Annex I to the UNFCCC. These are developing countries. Requirement for which the quality test result is measure or a score (e.g. from 1-10 or high/medium/low) A state that has ratified the Kyoto Protocol. A problem identified in the review of a Party s emissions inventory or other information submitted by a Party in the context of the Kyoto Protocol. The process by which data from different registry systems is compared and inconsistencies are resolved. The complete re-installation and re-configuration of a software system from scratch. A software system for the accounting of transactions in AAUs, RMUs, ERUs and CERs. Includes national registries and the CDM registry. Generic term for national registries, the CDM registry and the transaction log. Process that describes how a new piece of software is deployed to the system in operation. Removals of greenhouse gases from the atmosphere through LULUCF activities. Such removals may lead to the generation of RMUs, CERs or ERUs. They are the opposite of emissions of greenhouse gases. Data Exchange Standards, Functional Specifications, Version <1.0> Page 29 of 41

30 RMU Robust Role Scalability Secretariat Stage Status TCP Transaction Transaction log True-up period UNFCCC Unit Universal time User User Acceptance Test User Interface Virus XML Removal units. These are tradable units generated on the basis of removals of greenhouse gases from the atmosphere through LULUCF activities under Articles 3.3 and 3.4 of the Kyoto Protocol. They may be counted by Annex I Parties towards compliance with their emissions target and are equal to one tonne of carbon dioxide equivalent gases. A characteristic of a software system that describes the extent to which it is protected from loss of service or data integrity. A role is a set of permissions for functions that a person is allowed to perform. A role may be assigned to a user (person) or a group. The ability of a software system to handle higher workload then initially planned without modifying the program code. Secretariat to the UNFCCC A uniquely identifiable step in a data exchange sequence. A characteristic given to transaction (e.g. initiated, terminated, completed) Transmission control Protocol. An operation applied to AAUs, RMUs, ERUs and CERs (issuance, transfer, cancellation, retirement, carry-over). An electronic database established by the secretariat to monitor the validity of transactions between registries. The period from the end of the commitment period (2012) until 100 days after the completion of the Kyoto Protocol reviews of emissions information relating to the commitment period. Transfers of units may continue to take place during this period. The true-up period may therefore last until some time in United Nations Framework Convention on Climate Change. This is the framework treaty to which the Kyoto Protocol is allied. Generic term for AAUs, RMUs, ERUs and CERs. Equivalent to Greenwich Mean Time (24 hour clock). A person (human being) who interacts with a system. A test performed by a user of the system against a set of predefined test cases. The interface used by a person to interact with an application. A software program that harms software systems or other software programs. EXtensible Markup Language. Standard used for structured data storage. Data Exchange Standards, Functional Specifications, Version <1.0> Page 30 of 41

31 Annex B Transaction Processes This annex outlines the processes of interaction that national registries, the CDM registry and the transaction log will need to undertake. The six main types of interaction processes, which the data exchange standards will need to support and be consistent with, are summarized in the table below. Type of interaction Relevant transactions and activities 1. Issuance Issuance of AAUs and RMUs in national registries Issuance of CERs in the CDM registry 2. Conversion Conversion of AAUs and RMUs into ERUs 3. External transfer Transfer and acquisition of AAUs, RMUs, ERUs and CERs between holding accounts in different registries 4. Internal transfer Transfers of AAUs, RMUs, ERUs and CERs to a cancellation account to prevent them being counted towards an Annex I Party's emissions target Transfers of AAUs, RMUs, ERUs and CERs to a retirement account to set them aside for being counted towards an Annex I Party's emissions target 5. Carry-over Carry-over of AAUs, ERUs and CERs to the next commitment period 6. Reconciliation Reconciliation of unit holdings data between registries and the transaction log NODE: Input Data acted upon through operation of the function A1 TITLE: Control Data required to ensure the function is carried out in the appropriate manner Resources Actors involved in the function Function 1 A11 Mechanisms Procedures taking place within the function Parent diagram Child diagram Output The desired outcome of the function NO.: The following diagram generically illustrates the method used in this annex to define the interaction processes between the registries and the transaction log. This method defines each process as a function (shown here in the generic parent diagram) and decomposes it further into sub-functions (shown here in the generic child diagram). Control Each function and sub-function is represented by a box. The specific operations contained within the boxes are not defined. However, the arrows represent the minimum set of constraints which will need to be applied in the operation of the functions and sub-functions: inputs, outputs, mechanisms, resources and controls. The remainder of this annex, including figures 1 to 5, applies this method to the six processes listed in the table above. The functions and sub-functions form the basis for interactions for registry systems and hence for the data exchange standards, in particular in relation to the exchange mechanism and the data transfer format. A confirm amount sub-function has been included in some parent diagrams. This operation is shown with dashed lines as it is not to be undertaken by the transaction log or the registries. However, this operation is included in order to show the context within which these registry systems are to exist. It is a necessary prior step to some of the functions of the registries and transaction log being undertaken. Input Sub-function 1 Output Resources Mechanisms Control Input Sub-function 3 Output Resources Mechanisms NODE: A11 TITLE: Child diagram NO.: Data Exchange Standards, Functional Specifications, Version <1.0> Page 31 of 41

32 Issuance of AAUs, RMUs and CERs The issuance of AAUs is undertaken by a Party in its national registry on the basis of its assigned amount (which is in turn calculated on the basis of greenhouse gas emissions during the base year). The issuance of RMUs is undertaken by a Party in its national registry on the basis of its removals of greenhouse gases through LULUCF activities. The issuance of CERs into a pending account is undertaken by the CDM Executive Board, in the CDM registry, on the basis of verified and certified reductions in greenhouse gas emissions through a CDM project activity. Issuance of such units is monitored by the transaction log. In figure 1a, the dashed function shows the confirmation of the amounts that may be issued as AAUs, RMUs and CERs. This is undertaken by means of inputs, resources, procedures and control rules under the Kyoto Protocol that are external to registry systems. These confirmed amounts act as a constraint on issuance, shown as the solid function, which is undertaken through registry systems. Figure 1b shows sub-functions decomposed from function 1 in figure 1a: Sub-function 1. The administrator of a registry initiates an issuance and, in doing so, specifies the quantity of units to be issued. This must be lower than or equal to the amount confirmed by the external processes. The registry generates, in accordance with the data transfer format, a transaction number for the issuance and a serial number for each unit to be issued, and informs the transaction log of the proposed issuance. Sub-function 2. The transaction log receives the information on the proposed transaction from the relevant registry as an input and verifies the validity of the issuance against: (a) The rules defining data formats, as established in the data exchange standards, (b) The rules defining discrepancies, based on decisions by the COP on the Kyoto Protocol, including with regard to the confirmed amount available for issuance (contained in the secretariat's compilation and accounting database in the case of AAUs and RMUs and in the CDM Executive Board information systems in the case of CERs). The transaction log informs the registry of its findings. Where the transaction log discovers a data format error, the registry must repeat its number generation or message, as appropriate, if it wishes to continue with the issuance. Where the transaction log discovers a discrepancy, it flags its record of the relevant unit holding in order to aid in conducting its checks on future transactions. Sub-function 3. In the event of no discrepancy being discovered, the registry concerned modifies its unit holdings data to record the newly issued units and informs the transaction log of its actions. Sub-function 4. In the event of a discrepancy being discovered, the registry terminates the proposed issuance and informs the transaction log of its actions. - Assigned amounts - LULUCF net removals - CDM project data - Parties - Expert review teams - Compilation and accounting database - CDM project participants - CDM operational entities - CDM Executive Board Amount available for issuance Issuance initiation by Party or CDM Executive Board - Registry - Transaction log - Compilation and accounting database - CDM Executive Board database Exchange standards - Sequence model - Data format rules - Discrepancy rules Issue AAUs, RMUs and CERs - Articles 5, 7 and 8 rules - LULUCF accounting - LULUCF limits - CDM rules Amount confirmation - Article 7.4 report - Annual inventories - Article 8 review - CDM verification process 1 A11 Confirmation of amount available for issuance - generation - Transaction validation - Modify unit records - Transaction termination Units are issued in the registry and recorded in the transaction log Sub-function 5. The transaction log receives the confirmation from the registry of its actions and, accordingly, updates its own records of unit holdings in the relevant registry. In the event that the registry has terminated the proposed issuance for which a discrepancy was discovered, the transaction log removes the relevant flag on its record of the unit. NODE: A1 Figure 1a: Context of issuance of AAUs, RMUs and CERs Data Exchange Standards, Functional Specifications, Version <1.0> Page 32 of 41

33 Issuance instruction by the Party or CDM registry, specifying no. of units - Assigned amount data - LULUCF data - CDM project data Generate numbers 1 Issuance proposal, with transaction number and record set (transaction type, serial numbers, destination account no.) Validate transaction - Data format rules - Discrepancy rules - Party's AA data 2 Registry - Transaction number generation - Serial number generation - Transaction log - Compilation and accounting database - CDM Executive Board database - Data format check - Disrepancy check - If a discrepancy, flag unit record in the transaction log - Earlier record set Notification of no discrepancy, with record set Modify unit records in holding accounts 3 Registry Log additions Notification of discrepancy, with record set - Earlier record set Terminate transaction Registry 4 - Stop processing - Log termination Confirmation of completion or noncompletion, with record set Confirmation of termination or non-termination, with record set Modify unit records in the transaction log Transaction log - Earlier record set 5 - Log new holdings - Maintain discrepancy flag, if appropriate - Remove discrepancy flags, if appropriate - Units are issued - Record is public - Inform secretariat of any discrepancy and any action taken NODE: A11 TITLE: Figure 1b: Issuance of AAUs, RMUs and CERs NO.: Data Exchange Standards, Functional Specifications, Version <1.0> Page 33 of 41