Registry Operator's Proposal
Registry Operator's Proposal - Unsponsored
[A Registry
Operator's Proposal is to be submitted as part of every new TLD application. In
case of applications for unsponsored TLDs, the registry operator will be the
applicant and should prepare and submit the proposal as part of the
application. In the case of applications for sponsored TLDs, the sponsoring
organization (or, where the sponsoring organization has not yet been formed,
organization(s) or person(s) proposing to form the sponsoring organization)
will be the applicant. The sponsoring organization should select the proposed
registry operator, have it prepare the Registry Operator's Proposal, and submit
it as part of the application.
Please place
the legend "CONFIDENTIAL" on any part of your description that you
have listed in item F3.1 of your Statement of Requested Confidential Treatment
of Materials Submitted.
The Registry
Operator's Proposal should be separately bound (if more than one volume, please
sequentially number them) and labeled: "Registry Operator's
Proposal." and must cover all topics described below. This page, signed on
behalf of the registry operator, should be included at the front of the
Registry Operator's Proposal.]
I.
GENERAL INFORMATION
D1.
The first section of the Registry Operator's Proposal (after the signed copy of
this page) should be a listing of the following information about the registry
operator. Please key your responses to the designators (D1, D2, D3, etc.)
below.
D2.
The full legal name, principal address, telephone and fax numbers, and e‑mail
address of the registry operator.
Headquarters: Diebold, Incorporated
5995 Mayfair Road
North
Canton, OH 44720
Regional Office: Diebold, Incorporated
3800
TABS Drive
Uniontown,
Ohio 44685
Gene
Marsh
Phone:
330-498-2670
FAX:
330-498-2889
D3.
The addresses and telephone and fax numbers of all other business locations of
the registry operator.
Diebold has over 110 main branch offices located throughout the USA and many other regional and smaller offices. We also have offices in 40 countries. Principal national offices are listed in the enclosed Annual Report. Further information is available upon request.
D4.
The registry operator's type of business entity (e.g., corporation,
partnership, etc.) and law (e.g., Denmark) under which it is organized.
Diebold is a corporation, publicly owned and listed on the NYSE (DBD). Diebold is incorporated under the laws of the State of Ohio
D5.
URL of registry operator's principal world wide web site.
D6.
Dun & Bradstreet D‑U‑N‑S Number (if any) of registry
operator.
00-446-9300
D7.
Number of employees.
10,000 worldwide.
D8.
Registry operator's total revenue (in US dollars) in the last‑ended
fiscal year.
$1,259,177,000
D9.
Full names and positions of (i) all directors, (ii) all officers, (iii) all
relevant managers, and (iv) any persons or entities owning five percent or more
of registry operator.
(i) and (ii) Please refer to our Annual Report, attached, for a complete listing of Diebold’s directors and officers.
(iii) Pertinent group managers:
Global Services
Robert Reho,
Vice President
Managed Services:
Thomas A.
Cappelli, Director
Technical Services:
Gene
Marsh, Senior Manager
Customer Technology & Support
Center
Jeff
Leisinger, Manager
Event Monitoring Center
Connie
Allton, Manager
Managed Services Business Development
Jacqueline
Grimm, Senior Manager
Remote Services
Paul
Fisher, Manager
(iv) There are no persons or entities that own more than five percent of Diebold.
D10.
Name, telephone and fax number, and e‑mail address of person to contact
for additional information regarding this proposal. If there are multiple
people, please list all their names, telephone and fax numbers, and e‑mail
addresses and describe the areas as to which each should be contacted.
Mr. Gene Marsh
Title: Senior Manager, Technical
Services
Phone: 330-498-2670
FAX: 330-498-2889
email: marshm@diebold.com
D11.
The full legal name, principal address, telephone and fax numbers, e‑mail
address, and Dun & Bradstreet D‑U‑N‑S Number (if any) of
all subcontractors identified in item D15.3 below.
No subcontractors, as defined in D15.3, will be used.
II.
BUSINESS CAPABILITIES AND PLAN
D12.
The second section of the Registry Operator's Proposal (after the "General
Information" section) is a description of the registry operator's Business
Capabilities and Plan. This section must include a comprehensive, professional‑quality
business plan that provides detailed, verified business and financial
information about the registry operator. The topics listed below are
representative of the type of subjects that will be covered in the Business
Capabilities and Plan section of the Registry Operator's Proposal.
[ ICANN will
extensively review and analyze this section of the Registry Operator's
Proposal. The content, clarity, and professionalism of this section will be
important factors in ICANN's evaluation of applications. We strongly recommend
securing professional assistance from financial and management consultants to
aid in the formulation of your business plan, in securing the necessary sources
of financing, and in preparation of this section.]
D13.
The Business Capabilities and Plan section should consist of at least the
following:
D13.1. Detailed description of the
registry operator's capabilities. This should describe general capabilities and
activities. This description also offers the registry operator an opportunity
to demonstrate the extent of its business and managerial expertise in
activities relevant to the operation of the proposed registry. The following
items should, at a bare minimum, be covered:
Diebold has created a global network,
connecting our services, operation, sales, manufacturing and support
organizations. Please see the following
URLs for additional information:
http://www.diebold.com/aboutus/locations.htm
http://www.diebold.com/aboutus/profile3.htm
Additional information can be found
elsewhere on our general website:
D13.1.1. Company information. Date of
formation, legal status, primary location, size of staff, formal alliances,
references, corporate or other structure, ownership structure.
·
Founded: Diebold was founded in 1859.
·
Incorporated under the laws of the State of Ohio:
8/11/1876
·
Primary Location: 5995
Mayfair Road
North Canton,
Ohio 44720
·
Staff: Diebold employs 10,000 associates
worldwide.
1,000 staff are employed in the North
Canton and Uniontown facilities.
·
Affiliates:
See attached List of Subsidiaries and affiliates.
·
Structure:
Diebold is governed by an elected Board of Directors which appoints our
executive team. We have developed a
global business structure around four major business units:
·
North America
·
Latin America
·
EMEA (Europe, Middle East and Africa), and
·
Asia/Pacific
·
Ownership:
Diebold is publicly owned and listed on the NYSE (DBD)
D13.1.2. Current business operations.
Core capabilities, services offered, products offered, duration of provision of
services and products.
Diebold has many business units,
including elements of manufacturing, service (field service technicians),
managed services, transaction processing, software design, professional
services and support. Diebold has
established a worldwide presence for its products and services
DIEBOLD SERVICES EXAMPLES:
DIEBOLD
ADVISOR
Diebold AdvisorSM is a service developed to receive, analyze and
response to status messages sent by an ATM machine. This was designed for
our customers to increase equipment availability (without additional capital
expense), manage performance, and reduce costs.
With Diebold AdvisorSM, Diebold utilizes internally developed technology that has been
customized to handle multiple customers. It receives and translates the
status messages sent by an ATM into a fault code.
Once received,
Diebold remotely dispatches a service vendor or branch location employee based
upon a pre-defined escalation procedure. Notification will be made via DECAL,
pager, fax, or voice. Diebold monitors the progress of the event and will
automatically escalate a call to the next level if the notified party does not
respond. Diebold executes these procedures until a notified service vendor
acknowledges and responds to the call. When a call is acknowledged, the system
continues to track the call until it is closed and the ATM is repaired and
placed back in service.
Once received,
Diebold remotely dispatches a service vendor or branch location employee based
upon a pre-defined escalation
SERVICE DESCRIPTION
Service
Offerings
The following
description pertains to two levels of service that will be offered with Diebold
AdvisorSM
Limited
Service Monitoring
In the Limited
Service model, Diebold will receive all status messages sent from the ATM or
network. Once a status message is received, Diebold will open a trouble ticket and
notify a single point of contact. Notification will be made via DECAL, pager,
fax, or voice. Once notification is made, Diebold will automatically close the
trouble ticket with no acknowledgement required. Call escalation to ensure
someone is dispatched to repair the ATM is not offered as part of this service.
Full
Service Monitoring
The Full Service
model is similar to the one above but tracks the repair cycle of the ATM.
Diebold will receive all status messages sent from the ATM or network. Once a
status message is received, Diebold will open a trouble ticket and notify
contacts based upon a pre-defined escalation procedure. Notification will be
made via DECAL, pager, fax, or voice. Once notification is made,
Diebold will wait to receive an acknowledgement from the notified party. If no
response is received in a pre-defined period of time, Diebold will
automatically notify the next contact on the list until an acknowledgement is
received. Once acknowledged, Diebold will track the progress of the call until
it is closed within DBD Advisor and the ATM is repaired and placed back
in service.
STANDARD
FEATURES
Limited
Service Monitoring
|
||
|
||
|
||
|
||
|
Full Service Monitoring
|
||
|
||
|
||
|
||
|
SERVICE
BENEFITS
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
UNIQUE
FEATURES/CAPABILITIES
Diebold receives Advisor SM
the raw status messages from the ATM
thereby providing more specific information about the nature of the
failure. Raw status messages sent to a transaction processor are
categorized and/or generalized so that by the time of service dispatch, the
technician only know in general terms, what is wrong with the ATM. The
ability to receive the new status messages provides for more accurate failure
analysis thereby reducing ATM downtime and increasing revenue.
Diebold permits
the outsourcing of the ATM monitoring function eliminating the need for a
financial institution to maintain a large operations infrastructure and
investment in monitoring equipment. Financial Institutions can refocus their
efforts on core business issues in today’s highly competitive world.
DIEBOLD
MANAGED SERVICES, TECHNICAL SERVICES
Diebold’s Managed
Services – Technical Services group maintains a Networking Solutions practice
that has been addressing our customers’ internetworking needs for more than
four years. Some of the services offer
include:
APPLIED NETWORKING
TECHNOLOGIES
The Networking Solutions Group can provide a variety of
solutions for the transfer of content to and retrieval of information from
Diebold ATMs and other network-connected devices.
Communications systems vary and should be a key element in
selecting the appropriate distribution method. Traditional methods of file
transfer, such as "sneaker-net" and low speed leased lines are
acceptable for small file transfers (screen images, configuration files,
journal files), but are unacceptable for the distribution of larger, multi-megabyte
files (such as MPEG video files, software applications, multiple screen
changes).
As bandwidth needs increase, the need for a scaleable
network infrastructure is apparent. Recent technological improvements make
dial-up, ISDN, high-speed leased lines and frame relay suitable and cost
effective for large content distribution and retrieval.
Diebold has developed the following four software models for
electronic distribution solutions:
·
Basic
File Transfer
·
Remote
Access and Control
·
Remote
File Transfer
·
Enterprise
Manager
ENTERPRISE
MANAGEMENT
Diebold Managed Services Technicians and Services
Systems Engineers provide a consultative role in the determination of the
appropriate enterprise management and content distribution solution. Diebold
maintains an "open systems" position, insuring that Diebold ATM’s,
servers, and security equipment are compliant with all industry accepted
enterprise distribution/management systems.
Diebold ATMs are compatible with many industry
solutions, such as HP Openview, CA-Unicenter, Tivoli TME-10 and Novadigm.
NETWORK AUDIT
AND ANALYSIS
Diebold Managed Services Technical Services
Group has developed a suite of services
to collect and analyze detailed information specific to the following ISO
defined areas of network management:
·
Security Management
·
Performance Management
·
Fault Management
·
Configuration Management
·
Accounting Management
Traditional network management products lack many of
these capabilities because they are primarily device-centric. Diebold’s
solution is designed for comprehensive management of the entire system or
network --not simple, narrow views of a single box at a time. At Diebold, we
view network management as more than pointing and clicking on one device at a
time to display a subset of data. Other vendors’ products currently do not
address how to make management more than a post facto problem isolation tool.
Diebold’s solution utilizes a very powerful SNMP data
collection engine, with integral network discovery, and summary reports based
on SQL queries to the attached SQL database(s). Unlike physical-oriented
products, our solution stores all similar data from all agents in about 300
database objects. These database objects contain full support for all standard
SNMP MIBs such as MIB-2, RMON, RMON-2, FDDI, ATM, and dozens of others. In
addition, the Diebold security audit solution supports Enterprise MIBs from a
variety of major networking vendors.
When the application stores data about port-based
errors or IP address-based statistics, it correlates data from different
vendors’ proprietary MIBs and data from standard MIBs into single unified
tables and reports. For example, you can easily determine the worst port on the
worst vendor's unit in your network. The application collects all of the configuration,
performance, security, accounting, and fault data from every vendor's network
device simultaneously and stores it in a standard SQL-compliant database. This
includes all MIBs -- not just a simple few.
The following steps are typically performed in the
Diebold security analysis solution:
Step 1 - Device Identification
The application discovers all SNMP manageable devices
on your networks automatically. It then takes the extra step of identifying
unique devices which have multiple interfaces and passwords. This process means
a router with 24 IP addresses on 24 interfaces will be identified as a single
unique network device ID, but with 24 alternate ways of reaching it. Many users
find it is very beneficial to learn unique SNMP devices versus learning unique
IP addresses of their networks (which is the approach used with most network
management software products).
With other network management software products,
network performance is severely degraded while the same data from all 24 IP
addresses on a single, multi-port router or switch is retrieved. Typically, in
these cases, reports will contain confusing, duplicate data.
Step 2 - Data Collection
In the Data Collection phase, the application
collects data from an unlimited assortment of SNMP MIBs (standard,
experimental, or vendor-specific enterprise MIBs), from an unlimited number of
SNMP agents, parses the responses, and then stores this parsed data in hundreds
of database tables.
Because the application is not device-centric, it
does not store each SNMP agent's data in a different database table. Rather,
the application stores all like data from all agents in each table. Therefore,
queries can summarize any subject network-wide.
To reiterate, the application supports every
manufacturer and every model of all SNMP devices in the database and reports.
Step 3 - Network Health Summary
The Diebold security audit solution application
presents a simple unified view designed to look like a network management
software control center. From one location you can view the five screens that
summarize all five categories of network management. You can observe summary
statistics and alert notices for:
·
Security OK/Violations Detected
·
Performance Levels
·
Faults Detected
·
Configuration
·
Accounting
By simply clicking on any of these categories, you
will be provided with any level of detail desired -- including the raw data
stored in tables.
For further information, please contact the Diebold
Managed Services group.
Other Diebold Products and
Services
Please visit our website for more information:
Self service
Our technology empowers people worldwide to access services when, where, and
how they may choose. One popular example is the ATM.
Software
When it comes to software in the ATM and other self-service devices, Diebold is
one of the world's largest providers. But you'll also find Diebold software
driving most every other Diebold solution, both product and service.
Card-based systems
Diebold card-based campus systems are used at more than 400 colleges and
universities around the world. The cards are used to provide positive
identification, pay fees, purchase books and meals, access buildings and
events, withdraw money, and much more.
Security
Diebold provides a wide range of electronic security, physical security, and
facility products and services.
Professional services
Diebold professional services include strategic analysis and planning of new
systems, system integration, architectural engineering, consulting, project
management, and more.
Technical services
Services include remote monitoring and troubleshooting -- primarily for
self-service customers. Plus centralized monitoring for security customers. And
enhanced service for all.
Maintenance and repair
Keeping everything running is one of the world's most comprehensive service
organizations. In North America alone, there are more than 2,600 Diebold
service technicians deployed in more than 400 strategic locations.
Bringing it all together
There continues to be a critical need for effective systems integration. And
Diebold is there to fill that need. With innovative Diebold software to link
multiple hosts, networks, servers and databases. With the ability to package self-service, security, software, card
systems, network, technical and professional services into a single
comprehensive approach, Diebold provides the complete solution. We have the skills to integrate the various
self-service delivery channels, allowing Internet-based transactions and services
to be offered at the ATM and other devices
D13.1.3. Past business
operations/entity history. History, date of formation, legal status/type of
entity, initial services, duration of provision of services and products.
Diebold has an extensive business
history, dating back to 1859. A review
of our history of operation and successes may be found at:
http://www.diebold.com/aboutus/history.htm
We would be pleased to provide any
additional information required by the application review committee.
·
Founded: Diebold was founded in 1859.
·
Incorporated under the laws of the State of Ohio:
8/11/1876
·
Structure:
Diebold is a corporation governed by an elected Board of Directors which
appoints our executive team. We have
developed a global business structure around four major business units:
·
North America
·
Latin America
·
EMEA (Europe, Middle East and Africa), and
·
Asia/Pacific
Diebold supports its products and
services though their accepted useful life, except as specified otherwise by
law or regulation, or by contractual agreement.
D13.1.4. Registry/database/Internet
related experience and activities. Experience with database operation, Internet
service provision.
·
Industry first Internet-accessible ATM
·
Industry first Internet technology-based ATM
·
Industry first Internet-accessible services reporting system
·
Several managed services based on Oracle, DB2, Informix and
MySQL database systems
D13.1.5. Mission. The registry
operator's mission and how it relates to expansion into the registry operation
field.
Diebold’s vision is to “empower people
worldwide to access personalized information, products and services when, where
and how they may choose.”
Our mission is to provide defect-free,
competitive products and services on time to our customers.
Diebold will apply these basic
principles to the Registry Operation, as we have for many other services.
D13.1.6. Management. Qualifications and
experience of financial and business officers and other relevant employees.
Please address/include past experience, resumes, references, biographies.
A detailed treatise on the financial
and business officers and other relevant employees for Diebold is beyond the
scope of this document. Diebold will
provide specific information on officer and employee qualifications and
experience upon request.
D13.1.7. Staff/employees. Current staff
size, demonstrated ability to expand employee base, hiring policy, employee
training, space for additional staff.
Current Staff Size: 10,000 worldwide; 6,000 domestic (USA)
Ability to Expand: 200 technical personnel added in one year
(1999) to meet expanded customer service requirements.
Hiring Policy:
Affirmative Action: Diebold has an Affirmative Action Plan in
place that meets the government requirements and needs of the communities in
which we are located. Each of our
divisions and major locations throughout the country has an Affirmative Action
Plan.
Background checks for Diebold employees are
conducted by an independent organization.
These checks include:
·
Criminal including felony and misdemeanor
·
Motor vehicle record
·
Check on performance at previous employers
Drug Policy: Diebold has its own drug prevention policy
and program in place. Employment for
all candidates is contingent upon passing a drug test and a comprehensive
background verification which includes a criminal history check and past
employment confirmation. The drug tests
are administered by a third party within applicable state laws. The background verification is administered
through an independent, outside source.
Investigations: Diebold has very specific policies and
procedures relative to its investigation of its employees and potential
employees. Because of the interaction
between investigations of employees and various federal, state and local laws
and regulations, Diebold utilizes its existing policies and procedures relative
to Diebold's employees.
Non-discrimination. Diebold, Incorporated, is committed to the
continuing policy of equal opportunity in employment for all qualified persons
without regard to race, color, sex, creed, national origin, disability or
veteran status, except where sex is a bona fide occupational qualification.
Recruitment Policy. Individuals hired by Diebold are recruited
from newspaper ads, career fairs, college campuses placement offices, civic
organizations, high schools, vocational schools, private employment agencies,
employee and non-employee referrals, state employment agencies, business
contacts and walk-ins.
Generally, candidates are interviewed for requisite skills established by those in management with whom they would work.
Employee Training:
Diebold Associate Training
|
Introduction |
Diebold associates are
trained in the skills they will need to perform their jobs professionally and
effectively. The Diebold Education
Center is managed by the Development and Education (DevEd) organization. |
|
Training facilities |
Diebold has made a
significant investment into our company-wide training programs. We recently built, in conjunction with a
local college, a new 30,000 square foot state-of-the-art education center in
North Canton, Ohio. This facility
covers all training programs and courses offered by the company. Training also takes
place in divisional offices across the country. |
|
Associate education
development |
The curriculum includes
an associate development training progression. This approach to training our associates teaches the
fundamental cultural elements and core practices of the corporation. These include: ·
company vision ·
team skills, and ·
quality concepts. |
|
Core
courses |
All
associates complete four “Associate Core” courses within the first two years
of joining the company. They then
proceed to the appropriate associate or management training programs. The
Associate Core courses are: ·
Company Orientation ·
Achieving Teamwork ·
Quality tools, and ·
Producing Results
with Others |
|
Product
training |
Extensive
training in Diebold products and services is provided for every associate in
the company. Courses are developed as
an integral part of the product planning and development process. Our teaching and course development staff
is drawn from our best, most experienced product, service and software
personnel. |
|
Course
categories |
DevEd
offers over 120 courses which provide a comprehensive training opportunity
for all associates. Courses
categories covered by our professional training staff include: ·
Organization
Associate and Team Development ·
Quality Systems ·
Sales ·
Systems and Customer
Training ·
Service and Technical
Training, and ·
PC Skills. |
|
Evaluating
individual requirements |
Before
training begins, the training requirements for each associate are
evaluated. We match their education
and experience levels with our requirements.
This results in a curriculum that will fully qualify them to work on
their assignments. This applies for
all ·
administrative and
support personnel ·
service technicians ·
systems engineers,
and ·
sales people. The
DevEd catalog describes all courses that are offered within DevEd. This is used by associates and their
managers to plan each associate’s development and training. |
|
Measuring
progress |
Testing
is used throughout training to be sure ·
our instructors are
effectively teaching, and ·
our associates are
attaining high levels of understanding and performance. Feedback
networks throughout the company have been set up to monitor the effectiveness
of our training efforts. In
addition, we conduct regular customer satisfaction surveys to monitor our
effectiveness at delivering the right solutions and supporting our products
and services. |
Quality
of training - ISO
9000 |
DevEd
is actively involved in the corporate-wide effort to implement ISO 9000. Training program quality processes have
been established for all areas of the company, and include organizations such
as: ·
factories and design
and development ·
our nationwide sales
and service, and ·
our international
operations. |
Technical Training
|
Training classes |
Diebold Technical
Training formally holds classes for virtually all of our technicians each
year. These classes take place at our
home office training facilities and field offices. |
|
Product oriented |
Our classes are mostly
product oriented, which range from Diebold vaults, timelocks, alarms, remote
banking and ATMs through a variety of Third Party products which include bank
teller terminals, airline ticketing terminals, fuel monitoring,
point-of-sale, ATMs, comm networks and more. |
|
60 Product classes |
We teach approximately 60 different product classes
made up of almost 450 individual courses per year. These are conducted formally throughout the customer service
groups in Canton and divisional training facilities. These figures do not
include field on-the-job training sessions which do not require formal
training programs. |
|
Training formats |
We have adopted
different types or styles of training formats, including: ·
formal instruction
programs ·
video-based training ·
self-tutorial
programs, and ·
computer-based
training ·
web-based training |
|
Dispatcher
training |
Our
dispatchers attend an eight-week training program for an overview of our
products and service offerings. This
also includes training on: ·
customer service
programs ·
dispatching
techniques ·
computer record
keeping policies, and ·
customer response
procedures. Regular update sessions
are held as refresher courses and to familiarize the dispatchers with new
products, services and procedures. |
|
Video studio |
We have a video studio
where VHS training programs are produced.
Training also has the means to develop our own computer-based training
programs. |
|
Class structure |
Most of our formal
classes have a student to equipment ratio of 2:1. This is necessary since we feel that hands-on classroom
training is mandatory for our technicians to effectively learn the products. Normally, lab experience in the classroom
makes up 50-70% of the student's time. |
|
Certified instructors |
We certify our
instructors through an intensive program which includes our own Train-the
Trainer class. Our instructors are
product support engineers with a minimum of an associate degree or comparable
education such as military electronics schooling. Diebold sponsors an
Education Assistance program which encourages our instructors and field
technical staff to attend seminars or to take college-level courses. This enables us to keep abreast of the
leading edge of technology. All of our Canton-based
formal training programs are certified by the Council on Continuing
Education. We are sponsored by the
University of Akron which issues and tracks the CEU program for Diebold. |
|
Field class support |
Canton Technical and
Customer Training also supplies our field training facilities with training
packages and equipment so they can teach products that have evolved from
"new" to "mature" and are no longer taught at our home
office facility. |
Service Training
|
State-of-the-art training |
In our world of
constantly changing technology, it is critical that service personnel are
kept current on all products - old and new.
State-of-the-art technology requires state-of-the-art trained Customer
Service Engineers. That is why Diebold trains more than 1,500 people each
year at our National Training Center and area training facilities. Each Customer Service Engineer averages
125 hours of training a year. |
|
On-the-job training |
On the job training
schedules are coordinated by the field operating teams. Our quality control and Customer Service
Engineer training and improvement processes include certification, auditing
of performance and management visits. |
|
Ongoing training |
Our Customer Service
Engineers are trained and updated on an on-going basis in order to maintain
the highest level of technical ability.
Each course provides in-depth theory of operation and hands-on
servicing training. |
Team Training
|
Program design |
Diebold’s Team Training
program is designed to join the resources of our organization by using the
synergy and interdependence of the various disciplines of our corporate
culture. With this approach, Diebold
will be able to work more in concert with our customers in facilitating and
accommodating their efforts toward customer satisfaction. |
|
Raising the Standards |
The main focus of this
team training program is three-fold: ·
to raise the
standards of achievement for our CSEs ·
to make all CSEs
successful in their work, and ·
to provide the
highest quality and most responsive support available for our customers. |
|
Team
effectiveness model |
After
extensive research and experience, Diebold developed a model of team
effectiveness at our Lynchburg, Virginia, manufacturing facility. This model worked so well that we decided
to look at our customer service operations to see if teams could better serve
our customers. |
|
Team
structure |
Our
first efforts were quite successful.
As a result, we have created 47 territorial teams throughout the
United States involving 300 people.
These teams work with a high degree of interdependence for the
management of Customer Service Engineers (CSEs) and customer services. Teams
consist of: ·
Customer Service
Manager ·
Installation Manager ·
Territorial Advisor,
and ·
Technical Advisor. |
|
Management/
operation teams |
These
management/operating teams have five to seven members. They are responsible for supporting 30 to
35 CSEs. |
Team
Training
|
Training
program |
Each
team is given 60 hours of intensive team training designed to begin the
process of ·
training out old
independent operating styles, and ·
training in new
interdependent behaviors. |
|
CSE
teams |
After
three years and close facilitation, we have formed six CSE teams per
operating team. These teams have been
developed with the same purpose and criteria. |
|
Sales
teams |
We
now are training major and key account sales teams. These teams are made up of: ·
account executives ·
various sales persons ·
major account
technical coordinators, and ·
system specialists. |
|
Benefits |
The
team training program has provided major benefits for Diebold and our
customers. Due to our efforts and
through re-focusing our resources, we have enjoyed increases in: ·
productivity ·
personal
satisfaction, and ·
customer satisfaction. Because
of the success of this team training, we are adding the program to our new
focus factories. |
Team
Training
|
Goal
of corporate-wide support |
It
is our goal to run Diebold as a team since it is in the best interests of our
customers and will contribute to our continued growth. We will develop home office teams to
better support: ·
field service ·
customer response
center operations ·
technical support
groups ·
home office
administration, and ·
parts and repair
operations. |
|
Full-time commitment |
A team of full-time
associates (The Business Effectiveness Team) are devoted to the development
and maintenance of our teams. They
have been designing courses and programs for many years. They are now traveling throughout the
country training support personnel of the values, rewards and methods of
working together effectively. |
Space for Additional Staff: Diebold’s facilities have been designed for
easy and economical expansion as our business need dictate. We have expanded considerably over the last
decade, adding new office space and constructing new buildings.
The Diebold Customer and Technology
Support Center (CTSC) building was constructed in 1998 and has space for an
additional 75 associates in its current configuration. Diebold also retains the rights to
additional real estate immediately adjoining the CTSC for future expansion.
D13.1.8. Commercial general liability
insurance. Address/include amount of insurance policy, provider of policy,
plans for obtaining additional insurance.
Please refer to the enclosed sample
certificates of insurance for policy amounts and coverage details.
Scanned images are presented below:
D13.2. Business plan for the proposed registry operations. This section should present a comprehensive business plan for the proposed registry operations. In addition to providing basic information concerning the viability of the proposed operations, this section offers the registry operator an opportunity to demonstrate that it has carefully analyzed the financial and operational aspects of the proposal. At a minimum, factors that should be addressed are:
D13.2.1. Services to be provided. A
full description of the registry services to be provided.
-
Domain Name Registration
-
Domain Name Service
-
Domain Name Registration Management
-
Domain Named Registration Support
-
Domain Name dispute resolution initiation/referral
-
Domain Name Registration immediate billing
-
Domain Name Registration Support (24 hour)
-
Domain “Interim” hosting (NOT “Under Construction”)
o Referral site,
i.e. “For information call or write…”
D13.2.2. Revenue model. A full
description of the revenue model, including rates to be charged for various
services.
Diebold propose a for-profit registry
operation, while maintaining a competitive pricing structure for the Internet
community.
Diebold Incorporated chooses not to make public pro forma
financial information due to corporate policy and potential regulatory issues.
Diebold would welcome discussion of financial issues with
ICANN under a mutual confidentiality agreement.
For information regarding Diebold's financial performance
and history, please see visit http://www.diebold.com/investors/default.htm
for Annual Reports, SEC filings and related information.
Basic pricing for services is listed
below:
-
Domain Name Registration $10.00US/year
-
DNS Hosting for Registrants (at registration) N/C
-
Website “Placeholder” Hosting $5.00/month
-
TLD Registry Hosting To
be negotiated with TLD Sponsoring Organization
D13.2.3. Market. Market definition,
size, demand, accessibility.
Diebold places no boundaries on the
market for registration into the proposed TLDs.
It is anticipated that certain affinity
groups will migrate toward the TLDs as a natural, logical and organic method
for identification of sites and/or devices.
Below are first year potential numbers
of registrants for each TLD, listed in order of anticipated demand, and at 10,
50, and 90 percent confidence levels:
90 50 10
- .GLOBAL 275,000 550,000 1,100,000
- .SECURE 275,000 550,000 1,100,000
- .CASH 275,000 550,000 1,100,000
TOTALS 825,000 1,650,000 3,300,000
D13.2.4. Marketing plan. Advertising,
publicity, promotion strategy, advertisement development strategy, relationship
with advertising firm. Use of registrars and other marketing channels.
Diebold anticipates advertising through
the Internet and through targeted industry publications.
Diebold has relationships with several
advertising firms and is in the process of assessing potential marketing
strategies.
Diebold does not anticipate using
registrars at this time.
Diebold Incorporated chooses not to make public pro forma
financial information due to corporate policy and potential regulatory issues.
Diebold would welcome discussion of financial issues with
ICANN under a mutual confidentiality agreement.
For information regarding Diebold's financial performance
and history, please see visit http://www.diebold.com/investors/default.htm
for Annual Reports, SEC filings and related information.
D13.2.5. Estimated demand for registry
services in the new TLD. Projected total demand for registry services in the
TLD, effect of projected registration fees, competition. Please provide
estimates for at least 10%, 50%, and 90% confidence levels.
Diebold Incorporated chooses not to make public pro forma
financial information due to corporate policy and potential regulatory issues.
Diebold would welcome discussion of financial issues with
ICANN under a mutual confidentiality agreement.
For information regarding Diebold's financial performance
and history, please see visit http://www.diebold.com/investors/default.htm
for Annual Reports, SEC filings and related information.
D13.2.6. Resources required to meet
demand. Provide a detailed estimate of all resources (financial, technical,
staff, physical plant, customer service, etc.) required to meet the estimated
demands, using at least the 10%, 50%, and 90% confidence levels.
Diebold Incorporated chooses not to make public pro forma
financial information due to corporate policy and potential regulatory issues.
Diebold would welcome discussion of financial issues with
ICANN under a mutual confidentiality agreement.
For information regarding Diebold's financial performance
and history, please see visit http://www.diebold.com/investors/default.htm
for Annual Reports, SEC filings and related information.
D13.2.7. Plans for acquiring necessary
systems and facilities. Describe plans for acquiring all necessary systems and
facilities for providing the proposed services at each estimated demand level.
Provide details as to the scope, cost, and vendor for any significant planned
outsourcing.
Diebold has committed to providing the
necessary funding, resources and personnel to support the registry operation at
all anticipated levels of operation, including the potential for operating as
registry for other new TLDs.
Diebold Incorporated chooses not to make public pro forma
financial information due to corporate policy and potential regulatory issues.
Diebold would welcome discussion of financial issues with
ICANN under a mutual confidentiality agreement.
For information regarding Diebold's financial performance
and history, please see visit http://www.diebold.com/investors/default.htm
for Annual Reports, SEC filings and related information.
Diebold does not plan to outsource any
significant portion of the proposed registry, as defined in section D15.3 of
this document.
D13.2.8. Staff size/expansion
capability. Plans for obtaining the necessary staff resources, capacity for
expansion, hiring policy, employee training, space for additional staff,
staffing levels needed for provision of expanded technical, support, escrow,
and registry services.
Diebold has committed to providing the
required personnel, training and resources to support the registry operation at
all anticipated levels of operation, including the potential for operating as
registry for other new TLDs.
D13.2.9. Availability of additional
management personnel. How will management needs be filled?
Diebold has a wealth of management
experience within the company, and is always looking for talented, driven
management personnel to join our team.
Should the need arise, additional
management resources are available within the company and through a variety of
recruitment methods in use. Diebold has
addressed the need for additional operational and management personnel on many
occasions as business needs have dictated the necessity.
D13.2.10. Term of registry agreement.
State assumptions regarding the term of any registry agreement with ICANN or
the sponsoring organization. Note that the .com/.net/.org registry agreement
has a basic term of four years.
Diebold proposes a renewable four (4)
year term of agreement. We look forward
to working with ICANN to determine the details of a potential agreement.
D13.2.11. Expected costs associated
with the operation of the proposed registry. Please break down the total
estimated operational costs by the sources of the costs for each estimated
demand level. Be sure to consider the TLD's share of ICANN's cost recovery
needs.
Diebold Incorporated chooses not to make public pro forma
financial information due to corporate policy and potential regulatory issues.
Diebold would welcome discussion of financial issues with
ICANN under a mutual confidentiality agreement.
For information regarding Diebold's financial performance
and history, please see visit http://www.diebold.com/investors/default.htm
for Annual Reports, SEC filings and related information.
D13.2.12. Expected revenue associated
with the operation of the proposed registry. Please show how expected revenue
is computed at each estimated demand level.
Diebold Incorporated chooses not to make public pro forma
financial information due to corporate policy and potential regulatory issues.
Diebold would welcome discussion of financial issues with
ICANN under a mutual confidentiality agreement.
For information regarding Diebold's financial performance
and history, please see visit http://www.diebold.com/investors/default.htm
for Annual Reports, SEC filings and related information.
D13.2.13. Capital requirements.
Quantify capital requirements in amount and timing and describe how the capital
will be obtained. Specify in detail all sources of capital and the cost of that
capital (interest, etc.). Evidence of firm commitment of projected capital
needs will substantially increase the credibility of the registry operator's
proposal.
Diebold Incorporated chooses not to make public pro forma
financial information due to corporate policy and potential regulatory issues.
Diebold would welcome discussion of financial issues with
ICANN under a mutual confidentiality agreement.
For information regarding Diebold's financial performance
and history, please see visit http://www.diebold.com/investors/default.htm
for Annual Reports, SEC filings and related information.
D13.2.14. Business risks and
opportunities. Describe upside and downside contingencies you have considered
and discuss your plans for addressing them.
Diebold has performed an initial due diligence on potential business risks, and retains this information in confidence. Risk elements investigated include:
-
Competition
-
Risk of DNS dilution
-
Risk of
new/alternative technologies
-
Eventual/potential
phase-out of existing DNS structure
-
Changes in economic
conditions in the USA
-
Changes in economic
conditions globally
-
Other changes in
business conditions
Diebold
would consider discussing our view of our business risks in person with appropriate
ICANN personnel.
Diebold Incorporated chooses not to make public pro forma
financial information due to corporate policy and potential regulatory issues.
Diebold would welcome discussion of financial issues with
ICANN under a mutual confidentiality agreement.
For information regarding Diebold's financial performance
and history, please see visit http://www.diebold.com/investors/default.htm
for Annual Reports, SEC filings and related information.
D13.2.15. Registry failure provisions.
Please describe in detail your plans for dealing with the possibility of
registry failure.
“Failure is not an option”
-
Gene Kranz, Mission Control, NASA
Diebold believes opportunity for failure
in the proposed registry is extremely small.
However, Diebold also recognizes the need for the highest level of
stability and integrity for any new TLD registry.
Diebold wishes to enter into discussion with other new TLD registry operators regarding a failure mode operational transfer. Diebold believes an “interleaved failure mode operational transfer” would provide a very high level of stability even through the most dire of circumstances.
Diebold proposes that such discussions
be opened upon the selection of those applicants who will be providing new TLD
registry services.
D13.3. Pro‑forma financial
projections. Please provide detailed pro‑forma financial projections,
consistent with your business plan, for the demand scenarios that you estimate
under item D13.2.5. The pro‑formas should show revenue and expense
estimates broken down by detailed categories and should be broken down into
periods no longer than quarterly.
Diebold Incorporated chooses not to make public pro forma
financial information due to corporate policy and potential regulatory issues.
Diebold would welcome discussion of financial issues with
ICANN under a mutual confidentiality agreement.
For information regarding Diebold's financial performance
and history, please see visit http://www.diebold.com/investors/default.htm
for Annual Reports, SEC filings and related information.
D13.4. Supporting documentation. The
following documentation should be provided in support of the Business
Capabilities and Plan section:
D13.4.1. Registry operator's
organizational documents. Documents of incorporation (or similar documents).
Diebold is incorporated under the laws
of the State of Ohio. See attached
document of Good Standing.
D13.4.2.
References. A list of significant trade and credit references.
Trade References:
K-Byte Inc
1746 O’Rourke
Gaylord, MI 49735
Phone 517-732-6244
Fax 517-732-2538
Sankyo Seiki (America) Inc
3191-C Airport Loop Dr.
Costa Mesa, CA 92626
Phone 800-392-9076
Fax 408-988-8015
Lindsey Concrete
PO Box 578
Canal Fulton, Ohio 44614
Phone 330-854-4511
Fax 330-854-6664
Additional references are available upon request.
Credit References:
KeyCorp Credit Dept. (216) 813-4516
127 Public Square
Cleveland, Ohio 44114-1306 Acct # 42-700-0037
For over 40 years
National City Bank Davis
Bonner (216) 575-3285
National City Bank Center
P.O. Box 5756 Acct
# 2002288
Cleveland, Ohio 44101-0756
Additional references are available upon request.
D13.4.3. Annual report. The registry
operator's most recent annual financial report (or similar document). Audited
financials are preferred.
Please see our Annual Report, enclosed, for our latest
audited financials.
Diebold would welcome discussion of financial issues with
ICANN under a mutual confidentiality agreement.
For information regarding Diebold's financial performance
and history, please see visit http://www.diebold.com/investors/default.htm
for Annual Reports, SEC filings and related information.
D13.4.4. Proof
of capital. Provide evidence of existing capital or firm commitments of
capital. Demonstrated access to necessary capital will be carefully scrutinized.
Please see our Annual Report, enclosed, for our latest
audited financials.
Diebold would welcome discussion of financial issues with
ICANN under a mutual confidentiality agreement.
For information regarding Diebold's financial performance
and history, please see visit http://www.diebold.com/investors/default.htm
for Annual Reports, SEC filings and related information.
D13.4.5. Proof of insurance. Please
provide proof of the insurance described in item D13.1.8.
- Please refer to our sample
Certificates of Insurance, enclosed.
III.
TECHNICAL CAPABILITIES AND PLAN
D14.
The third section of the Registry Operator's Proposal is a description of the
registry operator's Technical Capabilities and Plan. This section must include
a comprehensive, professional‑quality technical plan that provides a
detailed description of the registry operator's current technical capabilities
as well as a full description of the operator's proposed technical solution for
establishing and operating all aspects of the registry. The technical plan will
require detailed, specific information regarding the technical capabilities of
the proposed registry. The topics listed below are representative of the type
of subjects that will be covered in the Technical Capabilities and Plan section
of the Registry Operator's Proposal.
[ICANN will
extensively review and analyze this section of the Registry Operator's
Proposal. The content, clarity, and professionalism of this section will be
important factors in ICANN's evaluation of applications. We strongly recommend
that those who are planning to apply secure professional assistance from
engineers and/or other technical consultants to aid in the formulation of the technical
plan and the preparation of the Technical Capabilities and Plan section of the
Registry Operator's Proposal.]
D15.
The Technical Capabilities and Plan section should consist of at least the
following:
D15.1. Detailed description of the
registry operator's technical capabilities. This should provide a detailed
description of the registry operator's technical capabilities, including
information about key technical personnel (qualifications and experience), size
of technical workforce, and access to systems development tools. It should also
describe the registry operator's significant past achievements. This
description offers the registry operator an opportunity to demonstrate the
extent of its technical expertise in activities relevant to the operation of
the proposed registry.
Diebold
currently has a 7 world-class data centers located in the US, Europe, Australia
and Africa. Each data center had bank
grade security and commensurate reporting systems, support infrastructure and
staff. We have, throughout the world
over 300 24 hour call center staff and 3000 local business hour call center
staff throughout the word speaking almost every language. The North American facility has 24 hour
trilingual coverage: English, French and Spanish.
D15.2. Technical plan for the proposed
registry operations. This should present a comprehensive technical plan for the
proposed registry operations. In addition to providing basic information
concerning the operator's proposed technical solution (with appropriate
diagrams), this section offers the registry operator an opportunity to
demonstrate that it has carefully analyzed the technical requirements of
registry operation. Factors that should be addressed in the technical plan
include:
Diebold
proposes a central registry/registrar model, with no additional, non-Diebold
registrars. The end user (registrant)
creates/modifies/deletes his own domain via ssl web form.
Diebold
proposes a system without email template processing. The system would, however, be capable of working through such
text-based browsers as “lynx”.
"The Internet dis-intermediates the middleman"
- Jim Clarke, Founder of Netscape
Our
system uses an integrated registry/registrar model where the registrant is,
itself, the registrar. The system uses
a very simple web-based domain registration/modification/deletion system.
While
it is not possible with our system to register a domain via email, email is
used to authenticate additions, modifications and deletions of domain names;
the registrant is sent a URL that completes the last step of the domain
registration/modification/ deletion process that actually commits the
information to the domain database.
No
direct email registration is possible directly however a market could exist for
third party email based systems that could interface with our web based system
should any entity care to pursue that.
The
system will utilize the most basic HTML/CGI features; that is, no frames, java
script or java. So, while a primitive email registration is not available
directly from us, primitive text only web browsers such as Lynx will work.
A
top level domain database record has very simple elements to it:
- Domain name
- Contact information, for
- Entity using the
domain
- Administrative contact
- Technical contact
- Billng contact
- Name servers
There
will be a simple web form for each of these elements.
Registration System Data Entry Flow
Registration
System Transaction Flow
D15.2.1. General description of
proposed facilities and systems. Address all locations of systems. Provide
diagrams of all of the systems operating at each location. Address the specific
types of systems being used, their capacity, and their interoperability,
general availability, and level of security. Describe in detail buildings,
hardware, software systems, environmental equipment, Internet connectivity,
etc.
The
registry system is housed at Diebold's Customer Technology and Support Center
facility on Green, Ohio, which is one of 7 data centers and other data
facilities Diebold operates throughout the world. Since one of Diebold's primary businesses is Self Service
Terminals (ATMs) and financial transaction networks, security is considered a
very high priority. Diebold employs
several levels of electronic, physical and design security at its
facilities. Details of the security
provisions will not be disclosed in a public document.
Diebold’s Larger Data Centers
And Related Facilities
Our
standard registry computing platform is a Unix-based quad 800 MHz Pentium
system with 4 gigabytes of RAM with a multiple 36 gigabyte SCSI-160 RAID array.
Connectivity
is provided through various providers; there are multiple connections: T1, T3,
OC3 and OC12 available.
The
registry software has been developed in-house, is thoroughly tested and had
been in operation for almost a year.
The
Oracle database engine will be used. Our system has been
benchmarked
(on the system outlined above) at 8000 transactions per minute. This is at least one order of magnitude
greater than is actually required (if not more than one order of magnitude) but
is what we feel is the minimum acceptable configuration. The database engine can handle databases in
the hundreds of millions of records, and certainly more than we would need for
the first 5 years.
Our
system is completely web based: the creation, modification, renewal and (if
need be) deletion of the domain can be easily accomplished through a simple web
form.
CREATION
OF THE DOMAIN
The
procedure to create a domain is as follows:
The
registrant accesses the registration web-page and performs a domain name lookup
into the whois database. Upon finding the
name is available they are prompted to enter the contact information for the
"organization using the domain name", the administrative, technical
and billing contacts and a password (that is used in the future so the
registrant can log in and modify (or delete) the domain).
At
this point the information is written to a "holding database" on the
database server, and, to guarantee the email address is valid and being used
with consent a message is sent to the contact of their choice (organizational,
administrative, technical or billing) stating that this domain is ready to
complete registration and they are given a link to a unique URL that will
continue the registration process. When
they go here they are prompted for a credit card number. An authorization check is performed on the
card to verify it's a "good" card and that there is sufficient credit
left on the card to make the payment.
If there is, the system now checks the real live database (not the whois
database) to see if perhaps the domain was registered since the last whois
database was generated. If it is still
really available then the credit card is debited and the domain information is
written to the live database.
Please
see figures above for more detailed outlines of the system logic.
There
are two unusual aspects to this process.
First, the initial registration procedure is halted and a URL is emailed
to the registrant to continue the registration procedure. This is to authenticate the registrant; that
is we don't want people registering domains in other peoples name without their
consent. Also, RFC1591 states the
domain manager must be on the Internet.
This provides that verification.
The
other part that may seem a little unusual is the idea that the potential
registrant can look up a name in the whois database, find that it is available,
continue the registration process, type in their credit card number and then
possibly discover the domain isn't actually free after all. The reason for this is, the whois database
is generated from the actual TLD zone database every 12 hours, so, if a domain
was registered in the last 12 hours it will not appear in whois but will be in
the TLD zone database.
This
approach does not give general access to this lookup unless the registrant is
serious. By the time the potential registrant has performed the lookup, we have
their credit card and have verified it is a valid card with sufficient
credit. If the name really is
available, the card will be debited, and the registrant will then be delegated
that domain.
There
are some tradeoffs being made here.
First, our domain database is not on the internet - for security reasons
(if it's not on the net it can't be hacked via the net) and we don't want to
give unfettered access to the general pubic to this database because we don't
want this database performance impeded with spurious lookups from would-be
attackers of automated processes ("bots") commonly used by
speculators. So, we force potential
registrants to give us their credit card before we make this check. In this way, we know the registrant is more
likely serious about the domain name.
This
is actually a simplified explanation of what currently happens "behind the
scenes" in that while they enter the domain name, contact information and
name servers these are all separate records in the domain database. Each record has a password in it that is
selected by the registrant at the time of it's creation. This is used for subsequent modification or
deletion of the domain information.
See
below for an example of the domain name record information:
Domain Name Entry
Domain Name
Contact
Organization
Name,
Address, Phone, Fax, Email
Administrative Contact Name
Name,
Address, Phone, Fax, Email
Technical Contact
Name
Name,
Address, Phone, Fax, Email
Billing
Information
Name, Address, Phone, Fax, Email
Existing Name Server(s)
Hostname
Host
TCP/IP Address
Domain Fields
Name
Organization
Technical Contact
Administrative
Contact
Billing Contact
Name Server 1
Name Server 2
“ “
Name Server 13
Contact Fields
First Name
Last Name
Address 1
Address 2
Address 3
City
State
Country
Zip
Phone
Fax
DNS Host Fields
Host Name
TCP/IP
When
a domain is created the creation and last modified fields in the record are set
to the current time.
A
copy of the registration is written to the history file.
The
domain will accessible on the Internet DNS when the next zone file is
generated. Zone file updates are
generated every 12 hours.
Note
that once a contact is on record with us, the registrant receive a
"nic-handle" that may be used in subsequent domain registrations in
lieu of having to re-type all the contact information all over again.
MODIFICATION
OF THE DOMAIN/CONTACT/HOST RECORDS
Mercifully,
modification of the domain is more straightforward than it's creation. Each record (contact, name server-host,
domain) has in it a password field. The
user can modify any of their records via a web interface as long as they know
their password. If they lose their
password they will need to fax a notarized statement proving they are who they
say who they are and indicate whether they would like the password sent via
email or snail mail. There may be a
small administrative fee for this.
HOST
MODIFY
The
host record associates the name server hostname with the IP address of the name
server. These form the “glue” “A” records in the TLD zone.
To
modify a host record the registrant would go to the "modify host" web
page on the registry, and log in with the host name. They will be requested for the password they assigned this host
when they created the record and if that matches correctly then they can change
the name server IP address with a form.
Each
host record contains time stamps for creation and last modified time/date; the
date/time modified is set to the current time, a copy of the old record is
written to the history file and the new record is written to the live
database. The change will be reflected
in the live DNS when the next zone file is generated. The contact for this name server is notified by email that this
host record had changed.
DOMAIN
MODIFY
The
domain record associates the second level domain name with contact records
(stored in the domain record as “handles") and name servers.
In
the TLD zone file these show up as NS records.
To
modify a domain record the registrant would go to the "modify domain"
web page on the registry, and log in with the domain name. They will be requested for the password they
assigned this domain at time of its creation.
If that matches correctly then they can change the name servers or
contact information.
Each
of the contacts are emailed that the change had been made and in the case where
the contacts have been changed both the
old and new contacted are notified by email.
Each
domain record contains time stamps for creation and last modified time/date;
the date/time modified is set to the current time, a copy of the old record is
written to the history file and the new record is written to the live database. The change will be refected in the live DNS
when the next zone file is generated.
CONTACT
RECORD MODIFY
The
contact record associates nic handle with physical contact
information
about an individual.
To
modify a contact record the registrant would go to the "modify
contact"
web page on the registry, and log in with the nic handle. They will be
requested for the password they assigned this contact when they created the
record and if that matches correctly then they can change any of the fields
with a form.
Each
contact record contains time stamps for creation and last modified time/date;
the date/time modified is set to the current time, a copy of the old record is
written to the history file and the new record is written to the live database. The change will be reflected in the live DNS
when the next zone file is generated. A
notification is send by email to the contact and in the case where the email
address was changed a notification is sent to the old address and the one it
was changed to just on the outside chance there is some funny business going
on.
D15.2.2. Registry‑registrar model
and protocol. Please describe in detail.
Diebold proposes to be both registry
and registrar. Details are explained
elsewhere in this document.
D15.2.3. Database capabilities. Database
size, throughput, scalability, procedures for object creation, editing, and
deletion, change notifications, registrar transfer procedures, grace period
implementation, reporting capabilities, etc.
The
database engine will be Oracle. This system has been benchmarked at greater
than 8000 transaction per minute. This is at least one order of magnitude
greater than is actually required (if not more than one order of magnitude) but
is what we feel is the minimum acceptable configuration. The database engine
can handle databases in the hundreds of millions of records, certainly more
than we would need for the first 5 years.
The
procedure to create a domain is as follows: the registrant
accesses
the registration web-page and performs a domain name lookup into the whois
database. Upon finding the name is
available they are prompted to enter the contact information for the
organization using the domain name, the administrative, technical and billing
contacts. A this point the information
is written to a "holding database" on the database server, and, to
guarantee the email address is valid and being used with consent a message is
sent to the Organizational contact stating that this domain is ready to
complete registration and they are given a link to a unique URL that will
continue the registration process. When
arriving at the site, potential
registrants are prompted for a credit card number. An authorization check is performed on the card to verify it's a
"good" card and that there is sufficient credit left on the card to
make the payment. If there is, the
system now checks the real live database (not the whois database) to see if
perhaps the domain was registered since the last whois database was generated. If it is still really available then the
credit card is debited and the domain information is written to the live
database.
There
are two unusual aspects to this process.
First, the initial
registration
procedure is halted and a URL is emailed to the
registrant
to continue the registration procedure.
This is to authenticate the registrant; that is we don't want people
registering domains in other peoples name without their consent. Also, RFC1591 states the domain manager must be on
the Internet, so we're checking that here, too.
The
other part that may seem a little unusual is the idea that they can look up a
name in the whois database, find it's free, continue the registration process,
type in their credit card number and then possibly discover the domain isn't
actually free after all. The reason for
this is, the whois database is generated from the actual TLD zone database
every 12 hours, so, if a domain was registered in the last 12 hours it will not
appear in whois but will be in the TLD zone database. Now, we are not going to give people access to this lookup of
unless they're serious, and by the time we've got their credit card and have
verified it's a valid card with sufficient credit; if the name really is
available, the card will be debited and they now have been delegated that
domain.
There
are some tradeoffs being made here.
First, our domain database is not on the internet - for security reasons
(if it's not on the net it can't be hacked via the net) and we don't want to
give unfettered access to the general pubic to this database because we don't
want this database performance impeded with spurious lookups from would-be
attackers of automated processes ("bots") commonly used by
speculators. So, we make people give us
their credit card before we ake this check.
That way we know they're serious
D15.2.4.
Zone file generation. Procedures for changes, editing by registrars, updates.
Address frequency, security, process, interface, user authentication, logging,
data back‑up.
Procedure
for Distribution
The
primary DNS server gets a zone file from the “real” live non-TCP/IP connected
database server via a proprietary protocol.
The
13 *published* name servers for the TLD act as secondary for the zone file for
the TLD from this primary. The primary
DNS server functions as a "phantom".
The
13 name servers are those listed in the root zone as authoritative for the TLD.
Once
every 12 hours the main database server generates a new zone file for the TLD
zone. This zone file is then validated by comparing the adds, modifications and
deletions to the adds, modifications and deletions recorded in the history
file. If they are different human intervention kicks in and the errors are
analyzed, isolated and corrected and the process is repeated. In either case when a new zone file has been
validated it is transmitted over a private link using a proprietary non-TCP/IP
protocol to the main ("phantom") name server for the zone. That server, in turn, receives the new
zone, validates it against its corresponding MD5 checksum and if it validates
properly the name server is restated and the new zone is now live on the
Internet. When this occurs the other
name servers for the TLD zone are informed of the change via the BIND notify
feature and automatically receive a new copy of the TLD zone via the AXFR
("secondary") mechanism. When
this is complete all name servers for the zone will be in sync.
All Diebold name servers run current levels of BIND
8. BIND 9 will be deployed as it
becomes available and stable for this environment.
D15.2.5.
Zone file distribution and publication. Locations of name servers, procedures
for and means of distributing zone files to them.
Diebold currently has a 7 world-class data
centers located in the US, Europe, Australia and Africa. Each data center had bank grade security and
commensurate reporting systems, support infrastructure and staff. Diebold will place name servers for the
registry in these locations as need dictates.
Initial placement of name servers will be
in our Customer Technology and Support Center located in Green, Ohio, USA; our
Worldwide Headquarters in North Canton, OH; one of our European Data Centers;
and one of our Asia-Pacific Data Centers.
D15.2.6.
Billing and collection systems. Technical characteristics, system security,
accessibility.
All
domains are paid for online at time of creation, so there is no initial billing
per se.
In
the event of a charge-back, the domain owner is asked to
explain. If the domain is not paid for in a
reasonable timeframe, it is deleted.
When
the domain renewal date is 3 months away the billing contact is informed by
email that the renewal is due in 90 days.
The contact is sent a URL to visit where the registrant may choose
to pay for the next 1 to 10 years of registration fees with a credit card
online. If the domain is renewed, all four domain contacts are notified that
the domain has been renewed, and for how long.
If
they do not renew within the first 30 days of the 90 day period, the billing
and administrative contacts are emailed notifying them that this is the second
renewal notice. Both are given a URL
where they can pay for the renewal online with a credit card. If the domain is renewed, all four domain
contacts are notified that the domain has been renewed, and for how long.
If
they do not renew within the second 30 days of the 90 day period, the billing,
administrative, organization contacts are emailed again notifying them this is
the third renewal notice. All are given
a URL where they can pay for the renewal online with a credit card. If the domain is renewed, all four domain
contacts are notified that the domain has been renewed, and for how long.
If
, 7 days before the renewal date, no renewal has been remitted, the billing,
administrative, organization and technical contacts are emailed once again
notifying them this is the fourth renewal notice. All are given a URL where they can pay for the renewal online
with a credit card. If the domain is
renewed, all four domain contacts are notified that the domain has been
renewed, and for how long.
If
the domain has not been renewed by one day after the expiration date, the
domain name is placed "on hold" -
that is, it remains in the whois but is removed from the live DNS. Only the current owner of the domain can
re-register it. Anybody can pay for it,
but ownership stays with the listed contact.
If renewed the name goes back into the live DNS and the updated date is
changed to the current date and a record is written to the history file.
If
the domain has not been renewed 60 days after the expiration date, the billing,
administrative, organization and technical contacts are emailed once again
notifying them of final notice before the domain name is removed from the
DNS. Only the current owner of the domain
can re-register it. Anybody can pay for
it, but ownership stays with the listed contact. If renewed the name goes back into the live DNS and the updated
date is changed to the current date and a record is written to the history
file.
After
no less that 90 days and no greater than 120 days the domain is removed from
the DNS and whois databases, and is available for registration again by
anybody. A record is written to the
history database indicating the domain has expired.
D15.2.7.
Data escrow and backup. Frequency and procedures for backup of data. Describe
hardware and systems used, data format, identity of escrow agents, procedures
for retrieval of data/rebuild of database, etc.
The
primary database has private connections to two other offsite database servers.
Each time any record is written to the main database the same record is written
to these other two database servers.
Each
database server is backed up every 6 hours.
Backups are rotated to offsite locations every 24 hours.
The
nature of the Diebold implementation defines multiple off-site locations for
the production system. This reduces the
potential for downtime due to any specific system failure.
Diebold
will maintain hot-spare systems and cold-spare components at each site.
Diebold
maintains backup data sets via two principal methods:
IBM
ADSM (Tivoli Storage Manager) is used for daily backup of "changed"
and "new" data across our secure corporate intranet. Data set copies are maintained on a
large-scale HP9000 system. Copies of
the data sets are maintained, also daily, to another Diebold location on tape
in a secure vault.
Seagate
Backup Executive for on- and off-site complete backup sets. Copies of the data sets are maintained, also
daily, to another Diebold location on tape in a secure vault.
D15.2.8.
Publicly accessible look up/Whois service. Address software and hardware,
connection speed, search capabilities, coordination with other Whois systems,
etc.
Standard:
see TLD Policy.
Every
12 hours the main database server generates a new whois
file. This is transferred over a private
connection with a non-TCP/IP protocol to the main IP-connected whois server.
The main whois server, in turn, transfers the whois database to the other
whois servers using secure FTP. The other whois servers receive the new
whois database, validate it, and make it available for pubic port 43 query.
There
will be multiple A records for the domain whois.<ourTLD> and will respond
to the current, as-distributed whois client software. However, a modified whois client will be made freely available
(as both source code and binaries for common computing platforms) that will
query a whois server at random (to balance the load among all whois servers)
and will try another if it cannot communicate with the first attempted system for
whatever reason.
D15.2.9.
System security. Technical and physical capabilities and procedures to prevent
system hacks, break‑ins, data tampering, and other disruptions to
operations. Physical security.
Physical
Security
Diebold's
Customer Technology and Support Center is a UL rated monitoring facility with
multiple physical security measures in place.
The building has 24 hour guard service, multi-level card access and
video surveillance.
Communications
access into and out of the building is through multiple paths, reducing the
potential of a "line break" affecting service.
Technical
Security
Diebold
utilizes "best-of-breed" security practices for access to all
systems. Access is limited to those individuals with specific need to operate
systems. Diebold employs a variety of
intrusion detection and firewall techniques.
The
Diebold registry systems have been designed to reduce the number of potential
security-necessary access points.
Diebold
declines to provide specific details regarding security provisions in a public
document.
Diebold
would encourage ICANN representatives to visit our facilities to investigate
our physical and technical security methods.
D15.2.10.
Peak capacities. Technical capability for handling a larger‑than‑projected
demand for registration or load. Effects on load on servers, databases, back‑up
systems, support systems, escrow systems, maintenance, personnel.
Our
system has been benchmarked at greater than 8000 transactions per minute in
bursts. We are utterly confident we can
handle well over 100 transactions a second for sustained periods. There is no practical limit as to the number
of domains our system can handle in toto.
All
servers and backup systems are designed to sustain all anticipated load levels.
D15.2.11.
System reliability. Define, analyze, and quantify quality of service.
Diebold
has designed its registry system to have the highest possible level of
reliability:
-
Redundant servers
-
Redundant components within servers, where possible
-
RAID arrays for disk storage
-
Multiple communications paths
-
Stand-by communications capacity
In
addition, Diebold data center facilities are designed with the following:
-
Redundant Uninterruptable Power Supply systems (Liebert)
-
Redundant backup power generators (ONAN/Cummins)
-
Separate entry/exit paths for multiple communications paths for buildings
Diebold
has also designed the registry system to operate redundantly at multiple host
locations. In the event of catastrophic
event at a specific location, the system is designed to continue to operate
without interruption from another location.
D15.2.12.
System outage prevention. Procedures for problem detection, redundancy of all
systems, back up power supply, facility security, technical security, availability
of back up software, operating system, and hardware, system monitoring,
technical maintenance staff, server locations.
Diebold
has designed its systems and facilities to provide the highest level of outage
prevention.
Diebold
data center facilities are designed with the following:
-
Redundant Uninterruptable Power Supply systems (Liebert)
-
Redundant backup power generators (ONAN/Cummins)
- Separate entry/exit paths for multiple
communications paths for buildings
D15.2.13.
System recovery procedures. Procedures for restoring the system to operation in
the event of a system outage, both expected and unexpected. Identify
redundant/diverse systems for providing service in the event of an outage and
describe the process for recovery from various types of failures, the training
of technical staff who will perform these tasks, the availability and backup of
software and operating systems needed to restore the system to operation, the
availability of the hardware needed to restore and run the system, backup electrical
power systems, the projected time for restoring the system, the procedures for
testing the process of restoring the system to operation in the event of an
outage, the documentation kept on system outages and on potential system
problems that could result in outages.
Diebold
utilizes several methodologies for system recovery depending on the nature of
the event.
-
Communications
failure
o
Redundant
connectivity
o
On-site spares
o
Multiple sites
-
Component failure
o
Redundant
components, where possible
o
Redundant systems
o
On-site spares
o
Multiple sites
-
Host failure
o
Redundant hosts
o
On-site spares
o
Multiple sites
o
Full range of
backups
-
Software failure
o
Full range of
backups
o
On-site technical
staff
-
Acts of God /
catastrophic event
o
Multiple sites
o
Full range of
backups
o
Cold site
disaster recovery agreement with Sunguard
D15.2.14.
Technical and other support. Support for registrars and for Internet users and
registrants. Describe technical help systems, personnel accessibility, web‑based,
telephone and other support, support services to be offered, time availability
of support, and language‑availability of support.
Diebold
does not propose the use of registrars at this time.
Diebold
proposes a combined use of web support, email support and telephone support for
domain name registrations. Diebold
phone support facilities are available 24 hours per day.
Diebold
employs a sophisticated system of phone support and problem escalation. The details of the support infrastructure
are beyond the scope of this document.
Diebold encourages ICANN representatives to visit our facilities to
further investigate our support capabilities.
D15.3
Subcontractors. If you intend to subcontract any the following:all of the
registry operation function;
•
any
portion of the registry function accounting for 10% or more of overall costs of
the registry function; or
•
any
portion of any of the following parts of the registry function accounting for
25% or more of overall costs of the part: database operation, zone file
generation, zone file distribution and publication, billing and collection,
data escrow and backup, and Whois service please
(a)
identify the subcontractor;
(b)
state the scope and terms of the subcontract; and
(c)
attach a comprehensive technical proposal from the subcontractor that describes
its technical plans and capabilities in a manner similar to that of the
Technical Capabilities and Plan section of the Registry Operator's Proposal. In
addition, subcontractor proposals should include full information on the subcontractor's
technical, financial, and management capabilities and resources.
No subcontractors will be used as part of
the registry Operation based on this criteria.
By signing this Registry
Operator's Proposal, the undersigned certifies (a) that he or she has authority
to do so on behalf of the registry operator and, on his or her own behalf and
on behalf of the registry operator, (b) that all information contained in this
proposal, and all documents attached to this proposal, is true and accurate to
the best of his/her/its knowledge and information. The undersigned and the
registry operator understand that any material misstatement or
misrepresentation will reflect negatively on any application of which this
proposal is a part and may cause cancellation of any delegation of a top‑level
domain based on such an application.
____Signature
of Greg T. Geswein on original_
Signature
____Greg
T. Geswein_____________________
Name
(please print)
____Chief
Financial Officer_________________
Title
____Diebold
Incorporated__________________
Name
of Registry Operator
____September
29, 2000__________________
Date
(c) 2000 The
Internet Corporation for Assigned Names and Numbers
All rights
reserved.
Updated August
15, 2000
LIST
OF SUBSIDIARIES
All
Subsidiaries, Affiliates, etc.
(Active a/o October 1999)
ATM Finance, Inc. (Ohio)
Central Security Systems,
Incorporated (Hawaii)
DBD Investment Management
Company (Delaware)
DBD Resource Leasing, S.A. de
C.V. (Mexico)
DCHC, S.A. (Panama)
D-GT Acquisition, Incorporated
(New York) (merged with Griffin)
DSSS Panama, S.A. (Panama)
Diebold Argentina S.A.
(Argentina)
Diebold Asset Management S.A.
de C. V. (Mexico)
Diebold Australia Pty. Ltd.
(Australia)
Diebold Australia Holding
Company, Inc. (Delaware)
Diebold Brasil Ltda. (Brazil)
Diebold China Security Holding
Company, Inc. (Delaware)
Diebold Colombia S.A.
(Colombia)
Diebold Credit Corporation
(Delaware)
Diebold DPB S.A. (Argentina)
Diebold Finance Company, Inc.
(Delaware)
Diebold Financial Equipment
Company, Limited (China)
Diebold Foreign Sales
Corporation (St. Thomas, U.S.Virgin Islands)
Diebold France SARL (France)
Diebold Germany GmbH (Germany)
Diebold HMA Private Limited
(India)
Diebold Holding Company, Inc.
(Delaware)
Diebold Hungary Ltd. (Hungary)
Diebold International Limited
(United Kingdom)
Diebold Investment Company
(Delaware)
Diebold Latin America Holding
Company, Inc. (Delaware)
Diebold Mexico Holding Company,
Inc. (Delaware)
Diebold Mexico, S.A. de C.V.
(Mexico)
Diebold Midwest Manufacturing,
Inc. (Delaware)
Diebold of Nevada, Inc.
(Nevada)
Diebold OLTP Systems, A.V.V.
(Aruba, Dutch West Indies)
Diebold OLTP Systems, C.A.
(Venezuela)
Diebold Pacific, Limited (Hong
Kong)
Diebold Panama, Inc. (Panama)
Diebold Poland Sp. z o.o. (Poland)
Diebold Procomp Amazonia, Sao
Paulo, Brazil
Diebold Selbstbedienungssysteme
GmbH (Austria)
Diebold Self-Service Systems
(Former InterBold - New York General Partnership)
Diebold SIAB (HK), Ltd., (Hong
Kong)
Diebold Singapore Pte Ltd
(Singapore)
Diebold South Africa Pty
Limited (South Africa)
Diebold Southeast
Manufacturing, Inc. (Delaware)
Diebold Spain, S.L. (Spain)
Diebold SST Holding Company,
Inc. (Delaware)
Diebold Texas, Inc. (Texas)
Diebold (Thailand) Company
Limited (Thailand)
Diebold Transaction Services,
Inc. (Delaware)
Diebold-Safetell International
Security Limited (Australia)
Diebold Australia Pty Ltd
Tecron Security Pty Ltd
Safetell Cash Handling Pty Ltd
Safetell International Services Pty Ltd
Diebold Security & Services Pty Ltd
RLM Monitoring Pty Ltd
Griffin Technology Incorporated
(New York)
InterBold Pacific Limited (Hong
Kong)
InterBold Singapore Pte Ltd
(Singapore)
InterBold Technologies, Inc.
(Delaware)
Mayfair Software Distribution,
Inc. (Delaware)
MedSelect Systems, Inc. (Delaware) (merged into Diebold, Incorporated)
Nexus Software (Raleigh, NC)
NX Acquisition Corporation
(Delaware)
Pioneer Systems, Inc.
(Pennsylvania)
Shanghai Diebold King Safe
Company, Ltd. (China)
Shanghai Diebold Security
Products Company, Ltd. (China)
Starbuck Computer Empire,
A.V.V. (Aruba, Dutch West Indies)
The Diebold Company of Canada
Limited (Canada)
VDM Holding Company, Inc.
(Delaware)
Verdi & Associates
(Pennsylvania)
ALL
SUBSIDIARIES, AFFILIATES, ETC.
(Inactive)
Diebold Safe & Lock
Corporation (Ohio)
Electronic Financial Terminal
Services, Inc.
Guardian Burglar Proof
Equipment Company
Herring-Hall-Marvin Safe Corp.
(New York)
Herring-Hall-Marvin Safe
Company (Ohio)
Record Files, Incorporated
York Safe & Lock Company,
Inc. (New York)
York Safe & Lock Company
(Pennsylvania)
Shuttletrack Corporation