prop · GS0318 · 2004-09-28 00:00:00 — The minor version is not in valid format or is out of range. The account type is not in valid format or is out of range. The account identifier is not in valid format or is out of range. The installation identifier is not in valid format or is out of range. It is not possible for a person holding account to have a contact person or his details, or an installation or its details (as listed in section 11.1 of to Commission Decision 2004/156/EC) associated with The amount of allowances for the specified period requested to be issued exceeds the amount approved by the Commission in the national allocation plan. The acquiring account is not a Party holding account. The national allocation plan table has not been submitted to the Commission and therefore it is not possible for the issuance or allocation of allowances for the specified period to take place . The units requested to be converted into allowances must be AAUs that have been issued for a commitment period matching the commitment period for which allowances are being issued. The specified acquiring account is not the operator holding account which is associated to the specified installation. The installation does not exist in the national allocation plan table. The specified year does not exist in the national allocation plan table. The acquiring account is not the retirement account for the 2005-2007 Force-majeure allowances can only be issued prior to 30 2008. The amount of force-majeure allowances requested to be issued exceeds the amount approved by the Commission for the commitment The acquiring account is not the cancellation account for the 2005- The reduction in the number of allowances exceeds the correction to the as approved by the Commission. The number of allowances transferred is not strictly equal to the number foreseen in the for the specified installation and The installation does not exist. The number of allowances transferred for the specified installation and specified year as foreseen in the national allocation plan has already The specified year is not part of the period 2005-2007. The specified AAUs are allowances and therefore it is not possible to convert those AAUs into ERUs. The units requested to be issued do not have the correct allowance identification code and therefore it is not possible for the issue to take The units requested to be issued do not have the correct force majeure allowance identification code and therefore it is not possible for the issue to take place. Warning: approaching breach of the commitment period reserve. There is no mutual recognition agreement between the transferring registry and the acquiring registry that enables the transfer of Allowances issued for the preceding period may only be transferred to the cancellation account or retirement account for that period after 30 April of the first year of the current period. Allowances are not those issued for the 2005-2007 period. It is not possible to surrender allowances issued for the period 2005- 2007 for the period 2008-12 and subsequent five-year periods. The transferring account is not an operator holding account. It is not possible to surrender allowances issued for the current period for the previous period. Units are not eligible for surrender pursuant to Article 53. The number of allowances and force majeure allowances requested to be transferred to the retirement account is not equal to the number of allowances surrendered pursuant to Articles 52 and 54 The number of AAUs requested to be converted from allowances is not equal to the number of allowances surrendered pursuant to Article The number of units requested to be transferred to the retirement account is not equal to the number of allowances surrendered pursuant to Article 52 and 53. The transferring account(s) are not Party holding account(s). Units are not eligible for retirement pursuant to Articles 58 and 59. The number of CERs requested to be transferred to the cancellation account is not equal to the number of allowances surrendered pursuant to Article 53. The number of AAUs requested to be converted into allowances is not equal to the number of allowances cancelled. Specified unit type requested to be cancelled in advance of replacement is not an allowance issued for the preceding period. The number of allowances cancelled is not equal to the number of allowances to be cancelled pursuant to Article 60(a) and 61(b). The quantity of allowances cancelled from the transferring account is not equal to the quantity of allowances transferred back to this The transferring account(s) must be accounts referred to in Article 11(1) and (2). The acquiring account(s) must be accounts referred to in Article 11(1) and (2). There is an inconsistency between the registry and the CITL in the operator holding account unit blocks. There is an inconsistency between the registry and the CITL in the person holding account unit blocks. Information: there are no inconsistencies between the registry and the CITL in the operator holding account unit blocks. Information: there are no inconsistencies between the registry and the CITL in the person holding account unit blocks. There is an inconsistency between the registry and the CITL in the totals of the operator holding account unit blocks. There is an inconsistency between the registry and the CITL in the totals of the person holding account unit blocks. Information: there are no inconsistencies between the registry and the CITL in the totals of the operator holding account unit blocks. Information: there are no inconsistencies between the registry and the CITL log in the totals of the person holding account unit blocks. There is an inconsistency between the registry and the CITL in the Party holding account unit blocks. There is an inconsistency between the registry and the CITL in the retirement account unit blocks. There is an inconsistency between the registry and the CITL in the cancellation account unit blocks. Information: there are no inconsistencies between the registry and the CITL in the Party holding account unit blocks. Information: there are no inconsistencies between the registry and the CITL in the retirement account unit blocks. Information: there are no inconsistencies between the registry and the CITL in the cancellation account unit blocks. There is an inconsistency between the registry and the CITL in the totals of the Party holding account unit blocks. There is an inconsistency between the registry and the CITL in the totals of the retirement account unit blocks. There is an inconsistency between the registry and the CITL in the totals of the cancellation account unit blocks. Information: there are no inconsistencies between the registry and the CITL in the totals of the Party holding account unit blocks. Information: there are no inconsistencies between the registry and the CITL in the totals of the retirement account unit blocks. Information: there are no inconsistencies between the registry and the CITL in the totals of the cancellation account unit blocks. There is an inconsistency between the registry and the CITL in the replacement account unit blocks. Information: there are no inconsistencies between the registry and the CITL in the replacement account unit blocks. There is an inconsistency between the registry and the CITL in the totals of the replacement account unit blocks. Information: there are no inconsistencies between the registry and the CITL in the totals of the replacement account unit blocks. Reminder: the specified serial blocks of allowances issued for the previous period have not yet been cancelled pursuant to Articles 60 43.A registry and the Community independent transaction log shall complete the following stages of testing: (a)Unit tests: individual components shall be tested against their specifications. (b)Integration tests: groups of components, comprising parts of the complete system, shall be tested against their specifications. (c)System tests: the system as a whole shall be tested against its specifications. (d)Load tests: the system shall be subjected to peaks in activity reflecting the likely demands that will be made on the system by its users. (e)Security testing: any security weaknesses of the system shall be identified. Individual tests for a registry carried out as part of the testing stages set out in paragraph 1 shall be conducted according to a pre-defined test plan and the results shall be documented. This documentation shall be made available to the Central Administrator on request. deficiencies in a registry detected during the testing stages set out in paragraph 1 shall be addressed before any testing of data exchange takes place between that registry and the Community independent transaction log. The Central Administrator shall require a registry to complete the following stages of testing: (a)Authentication tests: the ability of the registry to identify the Community independent transaction log, and vice versa, shall be tested. (b)Time synchronisation tests: the ability of the registry to establish its system time and to change its system time in order to be consistent with the system time of the Community independent transaction log and UNFCCC independent transaction log. (c)Data format tests: the ability of the registry to generate messages corresponding to the appropriate process status and stage and to the appropriate format, set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC, shall be tested. (d)Programming code and database operations tests: the ability of the registry to process messages received which correspond to the appropriate format, set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC, shall be tested. (e)Integrated process testing: the ability of the registry to execute all processes, including all relevant statuses and stages set out in , , and , and to allow manual interventions to the database pursuant to , shall be tested. (f)Audit logging tests: the ability of the registry to establish and maintain the records required pursuant to Article 73(2). The Central Administrator shall require a registry to demonstrate that the input codes referred to in and the response codes referred to in , , and are contained within that registry's database and interpreted and used appropriately in respect of processes. The testing stages set out in paragraph 3 shall take place between the testing area of the registry and the testing area of the Community independent transaction log, established pursuant to Article 71. Individual tests carried out as part of the testing stages set out in paragraph 3 may vary to reflect the software and hardware used by a registry. Individual tests carried out as part of the testing stages set out in paragraph 3 shall be conducted according to a pre-defined test plan and the results shall be documented. This documentation shall be made available to the Central Administrator on request. deficiencies in a registry detected during the testing stages set out in paragraph 3 shall be addressed prior to a communication link between that registry and the Community independent transaction log being established. The registry administrator shall demonstrate that any such deficiencies have been addressed by the successful completion of the testing stages set out in paragraph 3. 44.By at the latest, each notify the Commission of the following information: (a)Name, address, city, postcode, country, telephone number, facsimile number and e-mail address of the registry administrator for its registry. (b)Address, city, postcode and country of the physical location of the registry. (c)The uniform resource locator (URL) and the port(s) of both the secure area and public area of the registry, and the URL and the port(s) of the testing area. (d)Description of the primary and backup hardware and software used by the registry, and of the hardware and software supporting the testing area pursuant to Article 68. (e)Description of the systems and procedures for the safeguarding of all data, including the frequency with which a backup of the database is undertaken, and the systems and procedures for prompt recovery of all data and operations in the event of a disaster pursuant to Article 68. (f)Description of the security plan of the registry established pursuant to the general security requirements under . (g)Description of the system and procedures of the registry in respect of change management pursuant to Article 72. (h)Information requested by the Central Administrator to enable the distribution of digital certificates pursuant to . subsequent changes shall be promptly notified to the Commission. For the period 2005-2007, each notify the Commission of the number of force majeure allowances to be issued, subsequent to an authorisation to issue such allowances being granted by the Commission pursuant to Article 29 of Directive 2003/87/EC. In advance of the 2008-2012 period and each subsequent five year period, each notify the Commission of the following information: (a)The total number of ERUs and CERs which operators are allowed to use for each period pursuant to Article 11(bis)(1) of Directive 2003/87/EC. (b)The commitment period reserve, calculated in accordance with Decision 18/CP.7 of the Conference of the Parties to the UNFCCC as 90 per cent of the Member States assigned amount or 100 per cent of five times its most recently reviewed inventory, whichever is lowest. subsequent changes shall be promptly notified to the Commission. National allocation plan table requirements Each national allocation plan shall be submitted in accordance with the formats set out in paragraphs 5 and 7. The format for submitting a national allocation plan table to the Commission is the following: (a)Total number of allowances allocated: in a single cell the total number of allowances that are allocated for the period covered by the national allocation plan. (b)Total number of allowances in the new entrants reserve: in a single cell the total number of allowances that are set aside for new entrants for the period covered by the national allocation plan. (c)Years: in individual cells for each of the years covered in the national allocation plan from 2005 onwards in ascending order. (d)Installation identification code: in individual cells comprising the elements set out in and in ascending order. (e)Allocated allowances: the allowances to be allocated for a specified year for a specified installation shall be entered into the cell connecting that year to that installations identification code. The installations listed under paragraph 5(d) shall include installations unilaterally included under Article 24 of Directive 2003/87/EC and shall not include any installations temporarily excluded under Article 27 of Directive 2003/87/EC. The XML schema for submitting a national allocation plan table to the Commission is the following: <xs:schema targetNamespace="urn:KyotoProtocol:RegistrySystem:CITL:1.0:0.0" xmlns:xs="" xmlns="urn:KyotoProtocol:RegistrySystem:CITL:1.0:0.0" elementFormDefault="qualified"> <xs:simpleType name="ISO3166MemberStatesType"> <xs:restriction base="xs:string"> <xs:enumeration value="BE"/> <xs:enumeration value="GR"/> <xs:enumeration value="IE"/> <xs:enumeration value="NL"/> <xs:enumeration value="FI"/> <xs:enumeration value="DK"/> <xs:enumeration value="ES"/> <xs:enumeration value="IT"/> <xs:enumeration value="AT"/> <xs:enumeration value="SE"/> <xs:enumeration value="DE"/> <xs:enumeration value="FR"/> <xs:enumeration value="LU"/> <xs:enumeration value="PT"/> <xs:enumeration value="UK"/> <xs:enumeration value="CY"/> <xs:enumeration value="CZ"/> <xs:enumeration value="EE"/> <xs:enumeration value="HU"/> <xs:enumeration value="LV"/> <xs:enumeration value="LT"/> <xs:enumeration value="MT"/> <xs:enumeration value="PL"/> <xs:enumeration value="SK"/> <xs:enumeration value="SI"/> <xs:simpleType name="AmountOfAllowancesType"> <xs:restriction base="xs:integer"> <xs:minInclusive value="1"/> <xs:maxInclusive value="999999999999999"/> <xs:group name="YearAllocation"> <xs:sequence> <xs:element name="yearInCommitmentPeriod"> <xs:simpleType> <xs:restriction base="xs:int"> <xs:minInclusive value="2005"/> <xs:maxInclusive value="2058"/> <xs:element name="allocation" type="AmountOfAllowancesType"/> xs:sequence> <xs:simpleType name="ActionType"> <xs:annotation> <xs:documentation>The action to be undertaken for the installation A == Add the installation to the U == Update the allocations for the installation in the D == Delete the installation from the For each action, all year of a commitment period need to be given xs:documentation> <xs:restriction base="xs:string"> <xs:enumeration value="A"/> <xs:enumeration value="U"/> <xs:enumeration value="D"/> <xs:complexType name="InstallationType"> <xs:sequence> <xs:element name="action" type="ActionType"/> <xs:element name="installationIdentifier"> <xs:restriction base="xs:integer"> <xs:minInclusive value="1"/> <xs:maxInclusive value="999999999999999"/> xs:restriction> <xs:element name="permitIdentifier"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:minLength value="1"/> <xs:maxLength value="9"/> <xs:pattern value="[A-Z0-9|-]+"/> <xs:group ref="YearAllocation" minOccurs="3" maxOccurs="5"/> xs:sequence> <xs:simpleType name="CommitmentPeriodType"> <xs:restriction base="xs:int"> <xs:minInclusive value="0"/> <xs:maxInclusive value="10"/> xs:restriction> xs:simpleType> <xs:element name="nap"> <xs:element name="originatingRegistry" type="ISO3166MemberStatesType"/> <xs:element name="commitmentPeriod" type="CommitmentPeriodType"/> <xs:element name="installation" type="InstallationType" maxOccurs="unbounded"> <xs:unique name="yearAllocationConstraint"> <xs:selector xpath="yearInCommitmentPeriod"/> <xs:field xpath=". <xs:element name="reserve" type="AmountOfAllowancesType"/> xs:sequence> <xs:unique name="installationIdentifierConstraint"> <xs:selector xpath="installation"/> <xs:field xpath="installationIdentifier"/> As part of the initialisation procedures set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC, the Commission shall inform the Secretariat to the UNFCCC of the account identification codes of the cancellation accounts, retirement accounts and replacement accounts of each registry. Communication link between the Community independent transaction log and each registry 45.From 1 January 2005 until the communication link between the Community independent transaction log and the UNFCCC independent transaction log is established, all processes concerning allowances, verified emissions and accounts shall be completed using a communication link with the following properties: (a)Secure transmission shall be achieved through the use of secure socket layer (SSL) technology with a minimum of 128 bit encryption. (b)The identity of each registry shall be authenticated using digital certificates for the requests originating from the Community independent transaction log. The identity of the Community independent transaction log shall be authenticated using digital certificates for each request originating from a registry. The identity of each registry shall be authenticated using a user name and password for each request originating from a registry. The identity of the Community independent transaction log shall be authenticated using a user name and password for each request originating from the Community independent transaction log. Digital certificates shall be registered as valid by the certification authority. Secure systems shall be used to store the digital certificates and usernames and passwords, and access shall be limited. Usernames and passwords shall have a minimum length of 10 characters and shall comply with the hypertext transfer protocol (HTTP) basic authentication scheme (). After the communication link between the Community independent transaction log and the UNFCCC independent transaction log is established, all processes concerning allowances, verified emissions, accounts and Kyoto units shall be completed using a communication link with the properties set out in the functional and technical specifications for data exchange standards for registry systems under the Kyoto Protocol, elaborated pursuant to Decision 24/CP.8 of the Conference of the Parties to the UNFCCC. Communication link between the Community independent transaction log and its authorised representatives, and each registry and all authorised representatives in that registry The communication link between the Community independent transaction log and its authorised representatives, and a registry and the authorised representatives of account holders, verifiers and the registry administrator, who are obtaining access from a network different from the one serving that registry shall have the following properties: (a)Secure transmission shall be achieved through the use of secure socket layer (SSL) technology with a minimum of 128 bit encryption. (b)The identity of each authorised representative shall be authenticated through the use of usernames and passwords, which are registered as valid by the registry. The system for issuing usernames and passwords pursuant to paragraph 3(b) to authorised representatives shall have the following properties: (a)At any time, each authorised representative shall have a unique username and a unique password. (b)The registry administrator shall maintain a list of all authorised representatives who have been granted access to the registry and their access rights within that registry. (c)The number of authorised representatives of the Central Administrator and registry administrator shall be kept to a minimum and access rights shall be allocated solely on the basis of enabling administrative tasks to be performed. (d)default passwords with Central Administrator or registry administrator access rights shall be changed immediately after installation of the software and hardware for the Community independent transaction log or registry. (e)Authorised representatives shall be required to change any temporary passwords they have been given upon accessing the secure area of the Community independent transaction log or registry for the first time, and thereafter shall be required to change their passwords every two months at a minimum. (f)The password management system shall maintain a record of previous passwords for an authorised representative and prevent re-use of the previous ten passwords for that authorised representative. Passwords shall have a minimum length of 8 characters and be a mix of numeric and alphabetical characters. (g)Passwords shall not be displayed on a computer screen when being entered by an authorised representative, and password files shall not be directly visible to an authorised representative of the Central Administrator or registry administrator. Communication link between the Community independent transaction log and the general public, and each registry and the general public The public area of the website of the Community independent transaction log and the public website of a registry shall not require authentication of its users representing the general public.