annex 15: operational requirements -...

UNFCCC/CCNUCC

Annex 15:

Operational requirements

Table of contents

Annex 15................................................................................................................................................... 3 Summary ......................................................................................................................................... 3 15.1 Service support .................................................................................................................... 3 15.1.1 Summary of support services........................................................................................... 3 15.1.2 Cross-references.............................................................................................................. 4 15.1.3 Configuration .................................................................................................................... 5 15.1.3.1 System configuration requirements.............................................................................. 5 15.1.3.1.1 Live ITL production environment ................................................................................ 5 15.1.3.1.2 Initialization environment ............................................................................................ 6 15.1.3.1.3 Other pre-production test environments ..................................................................... 6 15.1.3.1.4 Utilisation of resources at peak times ......................................................................... 7 15.1.3.1.5 Service desk support environment and tools.............................................................. 7 15.1.3.2 Primary data centre configuration and asset management.......................................... 7 15.1.3.3 Data centre operations and security (access, virus, OS, patches) .............................. 9 15.1.3.4 Network infrastructure ................................................................................................ 10 15.1.3.4.1 Network design and build ......................................................................................... 10 15.1.3.4.2 Links to the secretariat.............................................................................................. 11 15.1.3.4.3 Network deployment and migration .......................................................................... 11 15.1.3.4.4 Network operations and security .............................................................................. 12 15.1.4 Change management, releases and production control ................................................ 12 15.1.4.1 Major changes ............................................................................................................ 12 15.1.4.2 Minor changes and emergency fixes.......................................................................... 13 15.1.4.3 Planned software releases ......................................................................................... 13 15.1.5 Service desk................................................................................................................... 13 15.1.5.1 Technical administration for registries and STLs ....................................................... 13 15.1.5.1.1 Service desk duties................................................................................................... 14 15.1.5.1.2 Scope........................................................................................................................ 14 15.1.5.1.3 Responsibilities and boundaries ............................................................................... 15 15.1.5.2 Testing, pilots, roll-out, and initialization support........................................................ 17 15.1.5.2.1 Pilot testing with CDM registry and a limited number of national registries.............. 17 15.1.5.2.2 ITL application acceptance test ................................................................................ 17 15.1.5.2.3 STL initialization........................................................................................................ 18 15.1.5.2.4 Registry initialization ................................................................................................. 18 15.1.5.2.5 Support of migration and cut-over from a supplementary registry ........................... 19 15.1.5.2.6 Other ITL-related systems in the secretariat ............................................................ 19

UNFCCC/CCNUCC

15.1.5.3 Training....................................................................................................................... 19 15.1.6 Problem management and incident resolution............................................................... 19 15.1.6.1 Service Level Agreement ........................................................................................... 20 15.1.6.2 Escalation, resolution, and disputes........................................................................... 21 15.2 Service delivery.................................................................................................................. 21 15.2.1 Service level management............................................................................................. 21 15.2.1.1 SLA Reporting ............................................................................................................ 21 15.2.1.2 Customer satisfaction ................................................................................................. 22 15.2.1.3 Organisational support ............................................................................................... 22 15.2.2 Service planning............................................................................................................. 22 15.2.2.1 Availability management............................................................................................. 22 15.2.2.2 Capacity management................................................................................................ 23 15.2.3 Service continuity planning and support ........................................................................ 23 15.2.3.1 Continuity planning ..................................................................................................... 23 15.2.3.2 Continuity configuration for the live production environment ..................................... 23 15.2.3.3 Continuity for other environments............................................................................... 25 15.3 Strategic support to the secretariat.................................................................................... 26 15.3.1 Sub-contracts and procurement..................................................................................... 26 15.3.2 Support for the ITL ......................................................................................................... 26 15.3.3 Support for the Registry System Administrators Forum................................................. 27 15.3.4 Biennial contract reviews ............................................................................................... 28 15.3.5 Demonstrations .............................................................................................................. 28

UNFCCC/CCNUCC

Annex 15 Operational requirements

Summary

This Annex describes the ongoing tasks to be carried out by the Operator in running and supporting the data centre and service desk, in order to support the ITL.

Section 15.1 describes how ITL systems, networks, and services are to be designed, built and delivered for day-to-day operations in primary and secondary data centres.

Section 15.2 identifies how the service delivery will be managed and performance will be tracked, and how the Operator will provide business continuity services in the event of service interruption.

Section 15.3 identifies how the Operator will provide strategic advice and support to the secretariat

This Annex is organised following ITIL1 guidelines for service delivery and support. This document may be subsequently expanded using this order to form the basis of the Service Level Agreement between the Operator and the secretariat.

Unless explicitly stated otherwise, “the Operator” here refers to the vendor for the operational component of the ITL work, including the service desk, data centre operations, hosting, technical support specialists, and network design and operations. “The Developer” refers to the vendor of the development component.

15.1 Service support

Service support requirements include technical systems and data centre, service desk, and their support during the initial deployment of the ITL software.

15.1.1 Summary of support services

The Operator will:

- configure and design infrastructure to support ITL live production and pre-production systems, developed from the Developer’s specification

- support the operation of ITL system services, - participate in the change control process (including configuration management) - provide a service desk - escalate and manage problems

The Operator will provide services for:

- a live ITL production environment - a temporary pre-production initialisation environment - ad-hoc pre-production test environments - a service desk support environment

1 IT Infrastructure Library for technology service management

Annex 15: Operational requirements Page 3

UNFCCC/CCNUCC

These services will be provided from:

- a primary data centre - a secondary data centre - a resilient network infrastructure that joins both sites, the service desk, and the secretariat

These services will be provided over networks to:

- the secretariat using browsers and interfaces to some of its systems - other registries (e.g. those run by Annex B Parties, the secretariat’s CDM registry, and the

European Commission’s CITL) using agreed data exchange standards - the public and other parties via a data extraction or database shadowing system, a public

website and extranet for registry system administrators (out of scope of this RFP)

15.1.2 Cross-references

Refer to Annex 2 Statement of work for an overview of service delivery requirements.

The configuration of systems at the data centre(s) should be designed to meet Annex 11 Target performance quality.

Refer to Annex 12 Development requirements for software requirements and non-functional needs.

Refer to Annex 13 Software specifications for the ITL software specification.

Refer to Annex 14 Data exchange standards for the method of communicating between registries.


UNFCCC/CCNUCC

15.1.3 Configuration

15.1.3.1 System configuration requirements

Indicative core ITL system configuration

Client Registry Server(s)

`Client Registry PC

Web ApplicationServer(s)

DatabaseServer(s)

FirewallFirewall

InternetVPN Endpoint

VPN

Traffic betweenregistry server and ITLWeb application server

is encrypted

IPSec through firewallsand the Internet Communications

Hub

MessageQueue

Connected Registry Systems ITL system

This diagram is indicative and is not a specification

15.1.3.1.1 Live ITL production environment

There will be a live production ITL environment running at a primary data centre.

The software design calls for a transactional database system and a communications hub with a message queuing mechanism. It will provide application-level XML/SOAP services to remote systems running concurrently in registries that connect using IPSec over public Internet using a VPN and, optionally, over private data lines provided by registries. The ITL application will receive and pass on transactions initiated by registries and initiate reconciliation jobs against those registries in accordance with the Data Exchange Standard (DES) technical specification. SOAP connections will be made between fixed IP addresses over secure ports (for the production environment), and possibly over unsecured ports (for testing).

There will also be a DES-format connection to the CITL, using largely the same technical infrastructure as the links to registries.

The Developer may be granted a restricted, view-only, access to the ITL in order to discharge its 2nd-line support obligations.

The secretariat will also have interactive access to the ITL through an administration application (http-browser based), and an automated interface (to be designed by the Developer) that uses a similar DES technical approach to periodically update some specific data on the ITL.


UNFCCC/CCNUCC

There is a later need to give the secretariat access to data for reporting in an efficient format (e.g. perhaps by downloading system-generated datasets from a web site) and to regularly generate and extract certain technical and operational statistics that can presented on a public website and a private registers’ extranet site2. Although the ITL will serve out this data, these two functions are noted for information only and are not part of this RFP.

The live system in production will be a resilient design configured with automated internal fail-over mechanisms (in a cost-effective manner) and with limited operational or maintenance impact (e.g. chassis that are appropriately sized for growth, RAID systems that can be recovered and rebuilt during a single shift, hot-pluggable components, database partition sizes that easily fit onto backup devices, file systems with sufficient nodes, etc).

The whole system will be scalable, notably for the predicated periods of peak loading and reporting. The Operator will liaise with the Developer to gauge peak capacity and whether it is appropriate to temporarily acquire more processing power or to hold extra capacity in the data centre permanently. The Operator will provide a scalable network to suit this configuration, and include equipment to handle load balancing, switching, routing, and redirection.

Also see 15.2.3 for backup and fail-over requirements to a remote system at a secondary site.

On award of contract, an SLA will be agreed between the Operator and the secretariat regarding service performance and availability, noting the target performance quality.

The Developer will engage the secretariat’s technology function during the design of the infrastructure. The secretariat will review the recommended configuration for good practice and will consider the design in light of its long-term technology strategy. It will allow the Operator flexibility to produce a system using its own preferred approach, but will check for the use of commonly available layered products, portable across a wide range of platforms which should not place undue restrictions on possible future configurations. The novation issues of potential products and configurations will also be considered.

15.1.3.1.2 Initialization environment

An initialization environment will be used for participants to concurrently perform communications tests, and run pre-arranged test scripts in order to prove connectivity and conformance with the DES prior to switching over to the live environments. This initialization environment will use the same basic network infrastructure and the same type of software components as the live environment.

The processing needed for this environment will be relatively light, and the Operator should establish whether this environment can be run efficiently sharing the same hardware with either the live or backup systems, or will need a separate system. Consideration should be given to the effect it has on the smooth operation of the live production environment.

15.1.3.1.3 Other pre-production test environments

At various times in the future it may be necessary to add an extra test or staging environment. For example, it may be necessary to test new DES formats, application releases, new versions or configurations of layered products and applications with external participants on a pre-production environment, potentially on separate hardware to avoid conflicts with hardware, software, performance, and scheduling. Subject to satisfactory security monitoring, this environment may be made available 24/7 for national registries to perform their own free-format or unscheduled testing.

2 These future systems may require ITL applications to be linked into an LDAP-enable security infrastructure. The software applications will be designed so as not to exclude LDAP functionality.


UNFCCC/CCNUCC

At times this environment may need a unique configuration of hardware and layered products that is incompatible with the live production or initialization environment. The Operator will need to coordinate this with the Developer, registries, and the secretariat.

This environment will be provided on a “best endeavours”3 basis, under a more relaxed SLA than the live production environment.

15.1.3.1.4 Utilisation of resources at peak times

The ITL will be built in a manner that allows software components to be scaled and deployed over additional hardware to meet peak loading. The Operator will suggest a configuration, or occasional reconfigurations, of the network and systems in order to efficiently meet the secretariat’s requirements in a cost-effective way, balancing the need of seasonal throughput peaks against the availability of extra environments, and a high availability of backup.

15.1.3.1.5 Service desk support environment and tools

There will be a service desk to support operations, as described in: 15.1.5 . The Operator will supply it with appropriate support tools, including a trouble ticketing mechanism with call logging, contacts, and reporting facilities.

Reports will be produced for statistics from daily or intra-day ITL processing, service requests, and the monitoring of SLA performance.

The service desk will have access, through a secure network, to the Operator’s own monitoring tools that show the state of ITL system tasks or processes, transactions, queues, etc, in a simple manner. These monitoring tools may be based on current off-the-shelf products for enterprise management which complement, not replace, the specified ITL system administrator application.

15.1.3.2 Primary data centre configuration and asset management

The Developer will advise on the sizing of servers that will hold the queues, the communications hub, the ITL applications, and database. It will document this configuration for agreement with the Operator who will be responsible for installing and running the systems under normal circumstances. The secretariat and Operator will formally approve the chosen architecture and hardware configuration.

The Operator will liaise with the Developer to:

- indicate its requirements for operations, service desk, and installations - ensure that these system(s) meet the target performance quality and provide resilience from

end-to-end. - provide input to the software design regarding operability, particularly instrumentation,

monitoring, and interfaces to service desk and management software - ensure it receives adequate and reliable software and operating scripts. - participate in change management decisions with the secretariat and 3rd parties as required - the Operator will formally approve the production code, scripts, and documentation that it

receives from the Developer.

3 “Best endeavours”, e.g. a cheaper, basic level of support using normal staff during normal office hours, at a lower priority than the servicing of live systems


UNFCCC/CCNUCC

- the Operator will formally approve and accept the installation, and service desk interfaces

System elements will be distributed between Operator’s locations (ITL servers, helpdesk, communications) and the secretariat’s sites (interfaced systems). The secretariat will not host any ITL-related systems directly on its sites, other than the resilient network equipment supplied by the Operator.

Target performance requirements indicate a need for a primary data centre (ref. 15.1.3.2 ) and a secondary data centre for business continuity (ref 15.2.3.2). There may be a need to support extra locations in order to provide support for a service desk and for off-site storage of backups.

The location of the non-production environments is not mission-critical, and their locations can be sited in the most cost-effective, or simple environment.

Indicative configuration of locations

This schematic diagram is indicative and is not a specification

Operator-supplied communications

Internet / networks (normally inaccessible)

BACKUP

Operator’s Secondary site (location #2)

to public Internet

LIVE

Operator’s Primary site (location #1)

Secretariat’s LAN

Secretariat administration

(ITL.browsers, JI-IS, CDM-IS, etc)

UNFCCC secretariat (Bonn)

Operator WAN

Operator’s service desk

The Operator will provide and staff a primary data centre which will host the live production equipment and its associated network, power supplies, and network connections on a site in accordance with the performance quality. Either the primary site or the secondary site could be used to host the other, non-production, environments.

The primary data centre should include resilient features, particularly relating to power supplies and distribution, access, and data communications.

The Operator will have the capacity to purchase such equipment, its systems and associated software licences, install them and configure them, and manage their support, renewal, and ultimate retirement. It may do this on behalf of the secretariat, or in its own name where this produces cost savings that can be


UNFCCC/CCNUCC

passed on to the secretariat. It shall agree a scale of discounts for purchase and operational costs that will be passed onto the secretariat and its clients where appropriate.

The costs of purchasing equipment must be approved by the secretariat prior to purchase. The secretariat reserves the right to procure such equipment itself.

It will maintain an inventory of related equipment, layered products and their licences and ensure these are identifiable. It will track their ownership and their status throughout the life of the contract. It will record novation conditions and costs for those items of the ITL held for the secretariat and in its own name.

The Operator will directly manage all aspects of those subsidiary relationships under the contract including maintenance payments, renewals, and updates, and will arrange for those suppliers to have access to systems for repairs and maintenance under appropriate levels of supervision and security.

The Operator will be responsible for all technical activities relating to service support and service delivery, including:

- server and systems management - database management and DBA support - message queue monitoring and support - monitoring and systems management infrastructure - backups and restoration - sundries and consumables - accurate time synchronisation of its managed systems

The Operator will perform continuous monitoring of the systems, applications, and layered software products, possibly using a standard enterprise management infrastructure. There should also be daily and weekly checks of databases, file systems, log files, etc. as appropriate.

15.1.3.3 Data centre operations and security (access, virus, OS, patches)

The Operator will be responsible for protecting access and availability from compromise by external factors, and will administer end-user security through its service desk. The Operator ‘s support and protection responsibilities will include:

- security and restoration of backups, including off-site storage at a safe, secure location - vetting of personnel, monitoring and secure operating procedures - physical security and access to the data centre, including monitoring and security of

equipment - protection against power and environmental interruptions including fire, water ingress etc. - system-level access controls to the hardware, including network and connectivity, - database security level controls of users and applications, and any integration with LDAP

services if required - running applications software, after formal handover from the Developer - systems software, including OS, DBMS, etc - operating system (re-)configuration and prompt application of appropriate patches - virus monitoring, IDS, D-o-S precautions and monitoring

The Operator will not modify the transactional data, whose integrity is the responsibility of the authorised end-users and the users within secretariat.

During system design and before starting live operations, the Operator will conduct a risk assessment, which will be used to:


UNFCCC/CCNUCC

- identify and inventory assets - identify threats - identify vulnerabilities - review controls and rate their effectiveness - understand the effect on down-stream participants - propose new controls, with costings and indicate their potential value or benefit

This risk assessment will reviewed and audited internally by the Operator. Actions will be decided and agreed with the secretariat. It will be reviewed afterwards as part of the biennial contract review.

15.1.3.4 Network infrastructure

15.1.3.4.1 Network design and build

The Operator will be responsible for the design of the network within the primary data centre and backup site, and will specify and coordinate the configuration of remote access, as initiated by the other participants.

The Operator will liaise with the secretariat to establish network connections that meet the target performance quality.

The DES specifies all registries’ transactions to be conducted over Internet VPNs using IPSec. Some registries may choose to connect using some type of private line rather than plain Internet to guarantee Quality of Service (QoS). Other ITL data may be made available, by other services outside the scope of this RFP, to web sites and/or web services. The network design should consider:

- technologies (internet, SSL, IPSec over VPNs) - connections and domains (reliable and secure management of SOAP transactions, e.g. static

IPs, reverse proxies, standardising use of secure ports beyond the default port 80/443, content filtering/XML parsing at firewalls, routing and switching, IDS)

- Private networks / VPN / SSL equipment and security infrastructure (certificates, issuance, renewals, encryption4), firewalls, IDS, and logging systems

- monitoring and management tools within the data centre infrastructure The network will be resilient (using redundant, physically separated network entry points and alternative providers where appropriate) and support the operation of a primary data centre and backup site(s), with adequate QoS to support the primary systems and service desk (with the Operator providing private lines, ethernet over internet, etc. as appropriate for these key sites).

In addition, the Operator will monitor network technology developments and specify and recommend one or more sets of equipment that can be configured by qualified specialists in the end-user organisations to support its communications standards. This equipment should be commonly available technology with a long product life ahead of it as it will probably need to be supported and operated locally within the end-user’s country for some time.

The Operator will document its required connectivity standards and assist remote users while they configure and test it for secure operation with the ITL.

4 Note although triple-DES (Data Encryption Standard) cryptography is specified in other Annexes, it is being supplanted by Rijndael AES in secure environments. The network encryption policy that is recommended by the Operator should reflect the planned longevity of the system and practicality of support. It must also consider different national situations where strong encryption my not be legally possible.


UNFCCC/CCNUCC

15.1.3.4.2 Links to the secretariat

Resilient links with adequate QoS shall be provided from the Operator’s site(s) to the secretariat.

The Operator will be responsible for the purchase of the network, its equipment, its system and associated software licences. It will install them and configure them, and manage their support, updates, renewal, and ultimate retirement. Its communications will terminate on the secretariat’s site at a point of presence to be agreed with the secretariat. The purchase costs must be approved by the secretariat prior to purchase. The secretariat reserves the right to undertake the procurement process itself.

15.1.3.4.3 Network deployment and migration

The DES specifies that national registry connections will be made over a hardware VPN.

Current CITL users use certificates and SSL. The Operator will specify a VPN approach that can be adopted by the participants that need to connect to the ITL.

The Operator will support and encourage the other participants in the early migration to VPN technologies. The exact timing and funding for these links will be made by registries or CITL in collaboration with the secretariat.

The Operator will identify and recommend suitable networks and dedicated equipment5 and provide detailed instructions on its initial configuration and connection to the ITL. The specification will cover:

- VPN connections over public internet - Private line/VPN connections

Other participants will buy and install devices according to this standard specification, and will be responsible for setting up their own Q-o-S agreements and installing a VPN with security certificates etc. in conjunction with the Operator.

The Operator will consider the impact on both the registries’ and CITL’s networks and its network, including:

- ease of configuration - local availability of equipment and support in-country - security - reliability - throughput, performance and Q-o-S - value (including bulk discounting) - long-term support and maintenance

The Operator will coordinate, purchase, and supply security certificates6 and will assist remote users during their initial configuration. It will not be responsible for the long-term configuration or ongoing support of networks, equipment, or tools within a national registry.

5 Some possible network choices may be private line, ethernet over leased line, over fibre, virtual leased line, DiffServ etc. Example equipment may include Cisco PIX, Juniper Secure Access SSL VPN, or other current technology. Any choice should be available and well-supported in the countries where national registries and the CITL are hosted. The recommendation should be reviewed at least every two years in conjunction with technology refresh planning with the secretariat. . 6 Note the chosen certificate authority will need to support and authenticate certificates internationally.


UNFCCC/CCNUCC

15.1.3.4.4 Network operations and security

The Operator will be responsible for the continuous operation and support of the data centre network and its connections to the outside world in accordance with the design criteria above.

This includes monitoring of availability, performance, and security (including availability testing, identifying attacks, logs, firewalls, IDS, packet sniffing, tracing etc.) The Operator will need to supervise any packet-processing activities for firewalls or other special data routing as required.

15.1.4 Change management, releases and production control

The hosted systems will be in a framework where they can be managed under the constraints in Annex 11 while changes can be agreed and implemented in a controlled way.

Change requests may originate from many places, not just the Operator or Developer, including:

- incident reports, SLA management, financial requests - software enhancements and development / release plans - bug reports, capacity planning, security - changes in the data exchange standards

The Operator will develop a procedure to manage the change management processes for minor and major changes, and will facilitate changes through its involvement in the change forum.

15.1.4.1 Major changes

The Operator will be consulted on major planned configuration and operating changes, prior to referral to the change forum under the steering group. This may include producing outline cost estimations and drafting proposals. The Operator will review the operational impact of application changes.

After agreement, major changes will be passed to the Operator to plan and implement, in conjunction with other participants as required. The Operator will put in place a production control/configuration control process to ensure that, for major changes:

- the impact of changes are properly assessed by the correct organisations and specialists, - changes are tested - outage times and loss of connectivity is limited, using regular schedules where possible - databases and message queues retain their integrity and performance - hardware/networks/layered product configuration changes are identified in advance - changes are rolled-out on backup and live systems in a coordinated way and recoverable

way - costs and progress are tracked and reported back to the committee

Major changes will involve consultation of all relevant parties, including representatives from;

- the secretariat, including its contract and technology specialists - SLA, legal, contractual, and financial management, - the Operator’s technicians, service desk and technical specialists for capacity and security,

business continuity, etc - the Developer

Once a change is authorised, developed, and tested, the Operator will ensure:


UNFCCC/CCNUCC

- the service desk is fully aware of the impact and can coordinate this with business needs with

sufficient advance notice - changes are communicated internally and externally, in a timely way, through the Operator’s

liaison with participants, the RSA Forum and any other reliable communication mechanisms. - the impact on external participants is minimal

15.1.4.2 Minor changes and emergency fixes

Minor changes may comprise those changes with very well understood and limited impact, or those with minor data impact e.g. changes to static data, user profiles.

Most minor changes will not be urgent. They will be batched up together for testing and will go live together as a scheduled release.

For emergency fixes there should be an optional rapid change process that captures the essence of the above controls, the objective being to minimise time and inconvenience, while making sure that the service desk, secretariat, and others who need to know are aware at an appropriate time.

The process will include a check to make sure that changes and fixes are not applied unnecessarily.

15.1.4.3 Planned software releases

There is a versioning system for major and minor changes within the message format of the DES, which identifies how a message should be processed. The releases of the ITL application will reflect this. Formal changes of the DES will be agreed by the secretariat after consultation in the RSA Forum and will result in major or minor application changes.

In addition there may be needs to fix application bugs and make enhancements, and to make configuration changes. These will result in major or minor change requests.

The Operator will establish and document an agreed release mechanism with the Developer.

15.1.5 Service desk

15.1.5.1 Technical administration for registries and STLs

The Operator will provide a 1st line service desk which has overall ownership and visibility of problems. This will include:

- a trouble-ticketing system to record and track calls (both email and voice) - a reporting method that can summarise calls and show progress - access to the monitoring and restricted access to the data of the ITL - access to an information/knowledge base and issue-management forum7 - responsibility for overseeing the issues and updating the knowledge base with off-line

decisions - timely access to the status of problems recorded in any other systems

7 ITracker <www.cowsultants.com> has been used successfully to track issues between the European registries and the CITL. It is public domain software and could be used again. Account should also be taken of the collaboration tools set up by the Developer during the earlier phases of development.


http://www.cowsultants.com/

UNFCCC/CCNUCC

- agreed escalation procedures

These will be used by a service desk which will agree policies with the secretariat and enact them.

15.1.5.1.1 Service desk duties

The duties of the service desk are above and beyond a basic help desk. They will include:

- responding to user requests by email, phone, and fax - problem management and resolution - understanding the application and any new features - user liaison with the registries and STLs8 during their core business hours. This may include

sending out messages by fax, email, announcements, and coordincoordinating schedules. - Coordination and implementation of events, such as reconciliation between the ITL and

participants and ITL notifications sent to registries - low-level data administration (supporting the development and input of static data, assisting

registries and the secretariat when troubleshooting reconciliation issues) - setting up and modifying user access rights in accordance with the secretariat’s policies - receiving and replying to email messages, phone calls, and faxes from participants in a timely

way - providing basic transaction and other statistics on behalf of, or through, the secretariat, to

users - reporting on SLA performance (Ref: section 15.1.5.1.3 for an indicative list of the types of

SLA performance to be reported back to the secretariat. This will be refined with the secretariat prior to running a live service)

Note that the service desk will contain, or have rapid direct access to, the Operator’s application specialists, and have access to the environment in which the ITL is working, its users’ business priorities, and timings. There must be an induction process before a service desk member can field calls unaided and a support procedure to ensure timely access to application and business knowledge.

The Operator’s service desk will receive training from the secretariat in the overall business environment, from the Operator’s technicians regarding the configuration and preliminary diagnosis of operational problems, and from the Developer in the operation and diagnosis of common application problems. The Developer and the Operator’s data centre will provide 2nd-line support and will not normally be expected to field calls directly. The Operator and Developer will provide transparent access to each other’s bug log, change request, and trouble ticketing systems, and share information on releases and their schedules.

15.1.5.1.2 Scope

Participants will connect to the ITL from locations in Europe, Asia, North America and Oceania (see list of participating countries in Annex 1). The ITL’s transaction workload and service desk calls will be driven by transactions submitted from those time zones. The ITL service desk will be staffed accordingly to cover core business hours in those time zones9.

8 Note that the working language for the ITL and the RSA Forum is English. An ability to communicate with technicians in the participants in their native languages is not a pre-requisite, though it may be advantageous. The UN official languages are English, French, Spanish, Russian, Chinese, Arabic (though Chinese and Arabic are not official languages of participant countries). 9 These time zones imply that there may be calls to the service desk between 20.00 GMT Sunday to 24.00 GMT Friday. This corresponds to 09.00 Monday in New Zealand and 18.00 Friday in Ottawa, Canada. See Annex 11.


UNFCCC/CCNUCC

15.1.5.1.3 Responsibilities and boundaries

The general concept around responsibility is for the service desk to receive and deal with external calls, and resolve the majority of trouble tickets itself. This assumes the service desk has access to one or more well trained and informed specialists during its hours of operation, and access to user-friendly monitoring tools. It will normally be responsible for coordinating application issues and escalating major incidents.

The Operator will be responsible for the general good behaviour of the systems under its control and will not require direct access to the Developer during normal operations.

The Developer will be involved in 2nd-line support or development, directed by the service desk or the secretariat. Its response will normally be provided during its office hours, except in emergencies.

The secretariat will normally expect to be engaged when there are data problems or changes involving the application, or changes to access and security. Other services issues are reported to the secretariat periodically via an SLA performance report (addressing those items marked "inform" in the table below).

Component

Operator’s Service

desk Operator’s technicians Developer Secretariat

---------------------------- Technical -----------------------------

Ensure the availability of live production systems Secondary Primary inform Ensure the availability of non-production systems inform Primary inform

Maintain backups and resilience Primary Backup and resilience failures Secondary Primary inform

Restoration from backup Joint Joint System management and OS monitoring Primary

System or OS problem escalation Secondary Primary inform Layered product management and monitoring Primary

Layered product escalation Secondary Primary inform Application process monitoring Primary

Application process problem escalation Secondary Joint Joint inform Hardware service and monitoring Primary

Operating instructions and updates Secondary Primary System configuration documents and updates Primary Secondary Secondary

Operating scripts and Enterprise Mgmt integration Joint Joint Equipment specification Primary Secondary Secondary

Equipment purchase and receipt Primary inform Equipment installation and configuration Primary Secondary

Equipment inventory inform Primary Licences and renewals of production systems Secondary Primary inform

Licences and renewals of non-production systems Secondary Primary inform Network set-up and monitoring Primary

Network problem escalation Secondary Primary inform Equipment maintenance scheduling Secondary Primary

Performance issues Secondary Primary Secondary inform


UNFCCC/CCNUCC

Component

Operator’s Service

desk Operator’s technicians Developer Secretariat

Security set-up and monitoring Primary Security issues and escalation inform Primary inform

Change management of minor config. changes Secondary Primary inform Change management of major config. changes Joint Joint Secondary Joint

--------------------- Application and Service ----------------

Call handling and trouble tickets from external participants Primary inform

User administration and contacts Primary Secondary Application and log file monitoring Primary Secondary

Application problem escalation Primary Secondary ad-hoc inform Transaction monitoring Primary

Transaction problem escalation Primary ad-hoc Secondary Data reconciliation between participants Primary

Reconciliation data problem escalation Primary Secondary Reconciliation process problem escalation Primary ad-hoc ad-hoc inform

Data problem resolution Primary ad-hoc ad-hoc ad-hoc Initialization schedule and coordination Primary Secondary

Application enhancements inform inform ad-hoc Primary

Manual or scripted changes to static data Secondary Joint or Primary

Joint or inform

Manual changes to transaction data Secondary ad-hoc Primary Change management of minor app. changes Joint ad-hoc Joint Secondary Change management of major app. changes Joint ad-hoc Joint Joint

------------------------ Common issues ------------------------

Performance and workload planning Joint Joint Secondary inform Hardware faults, maintenance, and escalation Joint Joint inform

Drafting of contingency plans Joint Joint Secondary inform Activation of contingency plans Joint Joint inform

Legend:

Primary responsibility responsible for action and resolution, and coordination of response

Secondary responsibility must to be kept informed and participate in, or react to decisions

Joint responsibility Joint responsibility for action and resolution between organisations

Inform to be informed in event of a serious issue, periodically to receive summarised performance (e.g. SLA performance report)

Ad-hoc gets involved only if requested by other parties via service desk


UNFCCC/CCNUCC

Although the service desk may contain staff of mixed experience and abilities, it must be able to deal appropriately with these issues, and should have fast access to appropriately-qualified staff during each shift, in accordance with its SLA obligations.

Also see section 15.1.6 for problem management and resolution.

15.1.5.2 Testing, pilots, roll-out, and initialization support

The Developer and Operator will cooperate closely together during the testing and the start of ITL roll-out to its first group of users.

The Operator will schedule the involvement of the other Registry System Administrators and will also notify and schedule support from the Developer during the pilot testing and the initialization processes.

Although it will be involved at the start of the first tranche of initializations, the Operator will plan to phase-out the direct involvement of the Developer rapidly, and start to use it in its “normal” 2nd-line support role.

A number of tests are to be performed on systems hosted on the Operator’s infrastructure, as described in Annex 12, where responsibilities are clearly defined.

15.1.5.2.1 Pilot testing with CDM registry and a limited number of national registries

Four organisations have developed registries and the European Commission has developed the CITL. These organizations are expected to be available to assist in the external pilot testing of the ITL.

The CDM registry should probably be the first system to test against, as this has been developed under contract to the secretariat. This registry contains a subset of the functionality implemented by a national registry. Further pilot testing should be carried out with developers of national registries and the CITL.

Connectivity with each of these systems should be tested before scripted pilot tests are conducted in order to ensure smooth network running with external participants. Note that pilot testing may involved connections to pre-production environments or test environments at a different site. The Operator should identify an early opportunity to test basic network connectivity between its data centre and these sites, several weeks prior to pilot testing, and some time before initialization starts.

For pilot testing, the Operator should have in place an environment (pre-production or test) which includes servers, network, and a core of the application software.

The pilot tests will include scripted data tests and ad-hoc tests, provided by the Developer in accordance with the ITL design. The Developer will assist the Operator in understanding the tests and will collaborate in drawing up further test scripts as a basis for later initialization tests during this pilot stage. Tests will be run against good data sets, and against bad data sets to check that exception handling is properly managed in the applications.

At this stage, parts of the service desk should be ready to help with test and registry coordination, and it should start to gain familiarity with the systems through training and exposure. Site visits by the support organisation should be backed up by installation notes as part of a support knowledge base.

15.1.5.2.2 ITL application acceptance test

The Operator will receive, test, and, if acceptable, formally accept the live production application as fit for operations from the Developer. These will include a period of penetration, soak, and volume testing to prove application stability, and a performance test conducted with the Developer to ensure it can operate


UNFCCC/CCNUCC

in accordance with the target performance quality. The tests will confirm that the design is adequate and that the application, tools, and operational scripts operate and report back correctly to the Operator’s enterprise management infrastructure tools identified at the data centre and service desk. The Operator will mostly support the Developer in the conduct of these tests.

As described in Annex 12, there will also be tests that will be primarily managed by the Operator, including:

- Security and Access Control (Penetration Testing) - Fail-over and Recovery - Installation and Configuration - Operability

The Operator will receive, test, and, if acceptable, formally accept the live production application as fit for operations from the Developer.

Any issues should be resolved before acceptance or identified on an exceptions list for urgent resolution.

The secretariat will also perform its own acceptance test on some applications; the service desk systems should coordinate this with the other testing schedules.

15.1.5.2.3 STL initialization

The CITL is the only STL currently foreseen. The link between the CITL and the ITL will be informally tested during the pilot running to prove the link and data formats.

A formal initialization process will be defined and conducted for the CITL, following the same format as for registries. Final initialization of European registries will also include end-to-end processing from registry to ITL to CITL and back.

15.1.5.2.4 Registry initialization

The Operator will support each registry through an initialization process before it is allowed to connect to the live ITL environment. This initialization process, including tests, is specified in the DES and will ensure the capability and suitability of their hosting environment through:

- a documentation review - a connectivity test - a simple message test (such as a time test) and successful acknowledgement - test initialization scripts which check for conformance by exercising all major functions

including transactions, reconciliation and notifications, within the registry and the ITL - test initialization scripts which check for conformance by exercising major functions at the

registry against the ITL, another registry and, where appropriate, an STL

The Developer will assist the Operator during the first few initialization cases, before the Operator takes on the complete initialization procedure. The duties of the Operator will include:

- provision of service desk, primary support, coordination, scheduling of ‘slots’ - elaboration of documentation review criteria - technical documentation review - enhancement and distribution of test scripts - oversight of testing (remotely and on site, for major registries) - coordination and re-running or repeat tests - presentation of results and recommendations to the secretariat for approval - coordination of the schedule for activating connections


UNFCCC/CCNUCC

Documents for review by the Operator may include: a technical review of infrastructure, systems, network, operating processes and support procedures. The purpose is to ensure that the participant is able to maintain its own systems in good order. The Operator will supply technical specialists to do this review.

The Operator will coordinate the progress of each participant through these steps.

The Operator should be able to manage and smooth out its workload during initialization, as it will be responsible for scheduling participants and controlling the availability of the environment, under the general direction and agreement of the secretariat. The initialization environment will be needed for some months before live running of the production environment.

15.1.5.2.5 Support of migration and cut-over from a supplementary registry

The CITL is currently the only system used to log and store all transactional data from European participants. After successful completion of initialization, and agreement with European participants, the service desk will coordinate the activation of connections (in batches or all at once).. This will include migrating CITL data to the ITL. Refer to Annex 12 for its specification.

Migration coordination will include supporting the ITL and CITL software developers during the planning and testing of a data migration process on a pre-production environment. After successful testing, the service desk will coordinate dates with affected participants and support the deployment and operation of the migration process. During the migration, the service desk will coordinate and oversee a temporary suspension of data entry from the European registries, validate the loading, and manage the resumption of normal service, with the CITL now operating “behind” the ITL.

15.1.5.2.6 Other ITL-related systems in the secretariat

The Operator and service desk will also support the ancillary systems and interfaces connected to the ITL as described in Annex 12.

15.1.5.3 Training

The Developer will train the Operator’s staff in the use and operation of the ITL.

Refer to Annex 12 for a description of what this will entail.

15.1.6 Problem management and incident resolution

The service desk will be responsible for ensuring that all incidents are logged and reported up through the SLA performance reporting mechanism.

The service desk will be responsible for initiating problem escalation and identifying or coordinating key individuals and teams to deal with problems that result in user issues. It will develop a process to track these issues, with different types of resolution including temporary work-arounds to satisfactory completion. It will also identify key people who will liaise with the secretariat about high-profile service issues and systemic issues.

It will support the secretariat and Operator/data centre in ensuring that actions and lessons filter back into the organisations and 3rd parties. It may use an ITL broadcast message, newsletter, email, website or tracking system, as appropriate, to ensure that other parties are kept informed.

The Operator’s technical product specialists (operators, networks, DBA, systems managers, etc) will be responsible for ensuring that the service desk is informed of potential issues in a timely way, both manually and through regularly-run scripted health checks and performance reports.


UNFCCC/CCNUCC

15.1.6.1 Service Level Agreement

Target response times for different types of errors will be defined in a detailed SLA., which will reflect the market’s needs and the secretariat’s key performance indicators.

Trouble tickets will be received from authorised contacts within the participants or within the Operator, and will be rated:

- Critical: the system is effectively unavailable to many participants - High: the system is rendered unavailable to a single participant through e.g. unreliability,

inability to carry out transactions in a timely way - Medium: transactions are still possible, but obstructed through e.g. performance, stability, or

an unusual transaction error - Low: transactions are not obstructed

Callers will be asked to agree with the rating.

In the event of serious operational failure, service credits or rebates will be levied, at the secretariat’s discretion. The levying of service credits will be waived during the first 3 months of live operations.

Suggested SLA response times

Event Target NotesRespond to a telephone call

Immediate: 95% to be answered within 5 rings. All to be answered on the first call

Acknowledge an email Receipt of 95% of messages to be acknowledged within 30 minutes 100% within 1 hour

Acknowledge a fax Receipt of 95% of messages to be acknowledged within 60 minutes 100% to be acknowledged within 4 hours (48 hours if across a weekend, unless this is a scheduled working weekend)

Answer and resolve a low-priority incident against live production system

95% to be diagnosed, answered, and fully resolved within 24 hours of acknowledgement, or, if this takes it beyond the caller’s business hours, by 10am next morning (in caller’s time zone)

Answer and resolve a medium priority incident against live production system

95% to be diagnosed, answered, and fully resolved within 4 hours of acknowledgement, or, if this takes it beyond the caller’s business hours, by 10am next morning (in caller’s time zone)

Answer and resolve a high priority incident against live production system

95% to be diagnosed and answered within 2 hours of acknowledgement. 90% will be fully resolved within 4 hours. All will be fully resolved within 8 hours.

Failure to meet this target may result in

service credits

Answer and resolve a critical incident against live production system

All will be diagnosed and answered within 2 hours of acknowledgement. 95% will be fully resolved within 4 hours. All will be resolved within 8 hours.

Failure to meet this target may result in

service credits


UNFCCC/CCNUCC

Event Target NotesInvoke business contingency plans

Within 3 hours of problem identification Failure to meet this target may result in

service creditsRespond to a high priority ticket against a non-production system

All will be diagnosed and answered within 4 hours of acknowledgement (72 hours if across a weekend, unless this is a scheduled working weekend). 95% will be fully resolved within 24 hours. All will be fully resolved within 48 hours.

Respond to any other priority ticket against a non-production system

All will be diagnosed and answered within 48 hours of acknowledgement (72 hours if across a weekend, unless this is a scheduled working weekend). 95% will be fully resolved within 1 week.

Respond to an enhancement request

All will be logged within 48 hours of acknowledgement (72 hours if across a weekend, unless this is a scheduled working weekend).

Requests will be reviewed in

regular change control meetings

15.1.6.2 Escalation, resolution, and disputes

As part of the SLA, an escalation path will be agreed for resolution of issues and problems.

A procedure will be agreed to resolve disputes over responsibilities with the secretariat.

15.2 Service delivery

The Operator will manage the delivery of services through a service delivery framework. It will engage the secretariat in service delivery issues, communicate with participants, and take actions within its own organisation. It will have in a place a business contingency plan in case of failure of components relating to the main data centre or service desk.

15.2.1 Service level management

15.2.1.1 SLA Reporting

The service desk will coordinate and help prioritise outages and service changes through their knowledge of user’s priorities. It will track all types of problem and coordinate resolution between the different participants delivering the ITL service.

The Operator will be responsible for overseeing general availability statistics. It will use the service desk supported by technical product specialists (operators, networks, DBA, systems managers, etc) to ensure that there are appropriate availability statistics available through scripts and manually-generated reports.

Those specialists will report on the performance of the live systems. These reports will note:

- call logs: e.g. types of calls answered and their resolutions. This will be broken down by severity (C/H/M/L), problem type (e.g. software, connectivity, etc) and by party (e.g. user-reported availability)


UNFCCC/CCNUCC

- perceived availability: times when the network and communications hub have been

continuously available or unavailable (e.g. the ITL’s measure of user-perceived infrastructure availability)

- actual availability: times when the whole environment is available, as measured from the external network connection through to the CITL (e.g. the ITL’s measure of actual infrastructure availability), times when redundant systems have been unavailable or when processes have left the live systems vulnerable to failure (e.g. when one of two network lines had failed, when a backup failed, when there were unexpected delays or lack of coverage in either primary or secondary location).

- service times: availability and utilisation of service desk - activity: usage and transaction statistics measuring and categorising the volume and times

of transactions between participants, and the time taken to process them - participant availability: statistics on the success of reconciliation and of technical or

transaction error rates

This function and the reports will be trialled during initialization and regularised at the start of normal running.

More transactional-related reports will be produced through a reporting system which is outside the scope of the RFP.

15.2.1.2 Customer satisfaction

The Operator will manage a regular survey to gauge satisfaction and gather feedback from a representative sample of users. This will be collected biennially and reported to and reviewed by the contract steering group in combination with the biennial contract review.

15.2.1.3 Organisational support

The Operator is expected to contribute to the coordination and decision-making concerning the ITL. This role will include:

- participation in the ITL steering group - participation in the change forum - reporting on SLA performance, monitoring and issues escalation

15.2.2 Service planning

15.2.2.1 Availability management

The service desk will be responsible for overseeing general availability on a daily basis.

Using its knowledge of the business priorities of the participants, it will act as a focus for scheduling system downtime and minimising its impact (using fail-over systems as necessary). It will coordinate requests from the data centre and Developer, and will inform and obtain a mandate to implement changes from the change management process.


UNFCCC/CCNUCC

It will ensure that operations and software availability is measured and initiate process improvements as necessary.

15.2.2.2 Capacity management

The technical specialists will monitor and review performance capacity on a regular basis.

They will liaise with the service desk and use the change process to understand the downstream effect of business or technical changes, and will identify changes to head off problems in advance.

Capacity should be a standard agenda item in regular review meetings (probably held monthly) and future loading should not be forgotten when systems are apparently stable.

15.2.3 Service continuity planning and support

The target performance quality indicate that the Operator must develop an infrastructure with:

- a clear management structure with a recovery team always accessible in times of emergency - an infrastructure designed for disaster recovery of core systems with priority given to having a

standby system available within several minute’s notice - resilient internal networking and dual-path resilient external network connections - an infrastructure design that, in the event of equipment failure, minimises the opportunities to

lose transactions once they have been acknowledged - business continuity plans for service desk and administration functions - planning, drills, monitoring and escalation procedures which are regularly exercised - debriefing procedures so that lessons are learnt from outages

15.2.3.1 Continuity planning

The Operator will produce a business continuity plan for the data centres, networks, and service desk infrastructure and key personnel.

Once approved by the secretariat, this plan will include invocation criteria, including establishing policies that identify actions to take given certain bad circumstances:

- severity of failure - impact on market - estimated time to fix - risks of delay versus risks associated with invocation and recovery from invocation

It will include plans to fail-over to alternative arrangements, including a method of rapidly maintaining key service desk tools (people, access to the ITL system and support tools, and core communications tools such as phones, email, etc.) and hardware and software. The Operator should be careful that the cost of continuity arrangements is assessed and alternative arrangements should be proposed where better value can be identified.

15.2.3.2 Continuity configuration for the live production environment

There will be a fail-over system available at a secondary site in the event of service loss at the primary site. The target performance quality suggest that this system shall have the same performance as the


UNFCCC/CCNUCC

primary and will be designed to be kept nearly-current and available quickly, in the event of failure of the live environment, through a combination of:

- rapid restoration from regular and reliable backups - near real-time shadowing of database transactions - messages/inter-registry communications - equipment resilience (the fail-over systems need not be quite as resilient as the live

production system, though mimicking features such as disk RAID will help compatibility for tape restores)

The Operator will incorporate the most efficient mechanism into its design, integrating applications, software tools, hardware and networks appropriately. The Operator will therefore ensure that the fail-over mechanism is designed in an efficient way through close liaison with the Developer.

The naming/numbering of systems and databases shall support the agreed method of fail-over (e.g. use of multiple IP numbers, database naming, etc.)

The location of the secondary site should be chosen such that:

- it is physically close enough to the primary site for the network to transmit message files, database updates, and any disk shadowing/updates fast enough without interference from other processes

- it is physically close enough to the primary site to receive deliveries of backup tapes, data, software etc, in a timely way that does not jeopardise a timely recovery of systems in the event of invoking a recovery

- it is far enough away from the primary site that its operations are not reasonably likely to be jeopardised by denial of access to the primary area

- it has secure and adequate infrastructure (including power, voice and data connections) that are unlikely to be affected by a problem on the primary site


UNFCCC/CCNUCC

Possible configuration for resilience and business continuity

This schematic diagram is indicative and is not a specification

Operator’s environment, including enterprise management and helpdesk infrastructure monitoring connections, servers, databases, secure power, ...

There may also be existing internal systems such as LDAP, Email, Website tools, CMS/EDMS, etc.

Server set-up#1 at primary site (runs current live LIVE PRODUCTION environment

DB svr

INIT’N

INITIALISATION environment

Server set-up#3 located at either site (runs current

DB svr

UPG/TEST

UPGRADE/TEST environment Server set-up#4 at either site (runs special tests or next

External-facing systems in DMZ

Back-end systems on secure internal network

Resilient firewalls, switches, load

balancing, routers, redirectors,...

Resilient VPN over Internet and/or private

lines

Secondary network Primary

network

Shadow DB always kept up-to-date over networks

ITL app server

ITL app svr DB svr

LIVE

ITL app server DB svr

BACKUP

BACKUP environment Server set-up#2 at secondary site. Becomes LIVE when National

registries

Public internet

Secretariat

National registries

European Commission

Backup network connection(s)

To UNFCCC

Private lines

To CITL

Admin, service desk & reports

web svr

Admin, service desk & reports

web svr

ITL app svr

ITL app svr

ITL app svrITL comms hub

ITL comms hub

ITL comms hub

ITL comms hub

Message queue shadowing

15.2.3.3 Continuity for other environments

The non-production environments will be supplied for connectivity to other participants, and should be made available during their time zone. Beyond this, no special resilience requirements or back up facilities have been identified. Technical support can be supplied on a “best endeavours” basis during normal office hours unless specific coverage is requested e.g. for initialization in other time zones.


UNFCCC/CCNUCC

15.3 Strategic support to the secretariat

15.3.1 Sub-contracts and procurement

The Operator will manage sub-contracts on behalf of the secretariat. This will include procuring products, monitoring developments within those products and their vendors, and managing the ongoing maintenance and support.

It will inform the secretariat when vendor or product circumstances change significantly and make sure that it is adequately warned if maintenance or licence conditions change over the lifetime of the contract.

Where equipment or support contracts have been procured on behalf of the secretariat, the Operator will ensure that any discounts are passed on to the secretariat.

15.3.2 Support for the ITL

The Operator will provide strategic input to the secretariat on the ITL and related activities.

This input may include:

- technology advice – product selection, technical architecture and technology refresh - methods and process – business process modelling and impact assessment - development and implementation of process improvements - enhancements to the support of registry systems and the trading market - identification, development and implementation of standards - draft documentation, information gathering and statistics - participation in periodic quality reviews and audits - supporting the secretariat in meetings and demonstrations

This input will be provided to a large extent through the ITL steering group and its change forum, as well as through the biennial contract review process.

The input should take account of technology, practices and lessons learned in other fields and applications which are similar to the ITL. It should take account of potential synergy, and the need for integration, with other systems and activities of the secretariat.

The Operator will not be directly responsible for setting the long-term technology direction of the secretariat, but will advise and support it in its technology choices. The Operator will make the chosen technology work across the ITL and provide support to participants in implementing any implications for them

Note that the Developer may also be called in to advise on some of these issues and to identify and implement change.

In the future, the secretariat may be subject to occasional audits that relate to the operation of the ITL. The Operator should maintain adequate records and skills to be able support these events.


UNFCCC/CCNUCC

15.3.3 Support for the Registry System Administrators Forum

The secretariat will consult with administrators of registries and STLs through an RSA Forum in order to agree on procedures to ensure compatibility, accuracy, efficiency and transparency in the operation of registry systems. The Forum will focus on the technical operation of registry systems. Specialized working groups will meet in order to develop and recommend proposals to the RSA Forum.

The Operator will assist the secretariat in its role of facilitating and chairing the RSA Forum.

The RSA is expected to meet twice a year over the longer term, though it may meet more frequently at the beginning. The first meeting of the RSA Forum is currently planned for February or March 2006. It will set priorities among its activities, establish working groups and set frameworks and guidance within which they are to work. The specialist working groups will thereafter begin their work and will meet more frequently than the full Forum, as required.

Several topical areas have so far been identified for the development of “common operational procedures” to be consistently implemented by all administrators. The secretariat, as ITL administrator, will develop these, in cooperation with other administrators through the RSA Forum.

Common operational procedures identified so far

Subject Description Testing protocols and independent assessment reporting

Standard test protocols are to be developed and applied to ensure the appropriate functioning of all registry systems. The assessment of results is to be conducted in an independent fashion. Reports are to be provided to the teams conducting the official review of Parties’ implementation of Kyoto Protocol systems.

Initialization and maintenance of secure electronic communications

Clear obligations and responsibilities will be developed for registries and STLs to establish and maintain communications with the ITL. These should be robust enough to justify the suspension of communications in the event that relevant technical standards are not maintained.

Reconciliation of data between registry systems

There will be clear procedures and methods developed that coordinate the actions required to reconcile registry systems and, where necessary, the manual intervention by administrators to resolve inconsistencies.

Coordination of change in the DES

The DES will evolve over time. There will be clear procedures to coordinate the proposal, assessment, decision-making and implementation of changes.

Where consistent application by all registry systems is useful, but not crucial, recommended working practices are to be developed. These may cover issues such as system availability and recovery, user access agreements and technical improvements. Other information-sharing measures may be implemented, for example to share information on operational best practices.

The secretariat will assist the Operator in building up skills required in order to support the secretariat in its work with the RSA Forum.

The expected role of the Operator in the context of the RSA Forum includes:

- inputs to the work schedules, agendas and documentation the Forum and its working groups - analysis and development of procedures, practices and other measures for consideration in

the Forum - implementation of central activities under procedures (e.g. carrying out and reporting on

tests, maintaining information on participants, and collecting, assessing and recommending DES change proposals)


UNFCCC/CCNUCC

- Distributing and controlling releases of the DES and procedures to be implemented by

registry system administrators - Maintaining information and electronic communication among administrators (using other

secretariat managed systems, e.g. public website, secure extranet, listservs) - Knowledge-transfer and capacity-building of skills within national registry administrators.

Note that the Developer will also assist in some activities (e.g. preparation of test scripts).

15.3.4 Biennial contract reviews

In order to provide flexibility over this long contract period, for both the secretariat and the Operator, a biennial contract review will take place. The first review is to be completed by the end of February 2009 and subsequent reviews are to be completed in two-yearly cycles thereafter. Any contract revisions will generally be effective from the beginning of the next calendar year.

This biennial contract review is to:

(a) identify changes to, additions to, or the withdrawal of, services to be supplied by the Operator

(b) identify major technological and operational changes, including in response to changes in workload and technology availability

(c) identify a schedule of contract efficiencies that refines the service level around a changing business environment

(d) update the security processes and risk assessment for the ITL

(e) consolidate any changes which have occurred since the previous contract review

(f) apply indices (e.g. for inflation) to cost components for the period up to the next subsequent contract review

The contract review is to take place on the basis of the review scope and preferences stated by the secretariat and an assessment by the contract review team.

The contract review team (consisting mostly of representatives of the Operator) will propose, by 31 January prior to the completion of each contract review, revisions to the scope of work and SLA under the contract for the operational component of this RFP. The secretariat will assess the impacts of such revisions and provide feedback. Any revisions under the contract must be agreed by the secretariat.

15.3.5 Demonstrations

The secretariat frequently meets other interested parties, and will request the Operator to provide ad-hoc support with meetings and demonstrations relating to the ITL. Demonstrations may take place at the annual sessions of the COP/MOP, at regular RSA Forum meetings or on other occasions.

The objective of demonstrations will be primarily to show the functionality of the ITL to illustrate the carbon market which it supports. Detailed requirements for the involvement of the Operator will be provided by the secretariat on a case by case basis. The Operator will prepare the demonstrations in accordance with secretariat requests, where necessary in conjunction with the Developer. Technically, demonstrations will be carried out in an environment other than the ITL live production environment.

A major demonstration is foreseen to take place at the 2nd COP/MOP meeting in November 2006. The frequency, timing and location of other demonstrations is currently unknown.


UNFCCC/CCNUCC


For this reason, vendors must not include estimates of costs associated with demonstrations in their financial proposals (see Annex 10) to this RFP. Costs will be reimbursed in addition to the contracted sums agreed for this work, on the basis of unit rates specified in the financial proposal and travel costs determined in accordance with UN financial rules and regulations.

The Operator will be encouraged to participate in other related technical forums on its own account.