Global Registry Service Provider (GRSP) Policies
- Introduction
- Code of Conduct
- Survivability and Data Escrow
- Fees
- Registrar Support
- Technical Support Policy
- Help Desk Support Policy
- Escalation Policy
- Planned Outage Notification Policy
- Operational Test and Evaluation Support Policy
- Registry Reporting
1. Introduction
GRSPs are the Global Service Providers (GSPs) who offer Global Registry Services (GRS) for I-Names and I-Numbers. This section contains the policies governing GRSPs.2. Code of Conduct
The XDI.ORG GRS is provided as public infrastructure to enable individuals and organizations to access, navigate, and use the services of the2.1. GRSP Code of Conduct Policy
GRSPs MUST at all times operate as a trusted neutral third-party provider of Global Registry Services and MUST comply with the following Code of Conduct provisions:-
With regard to GRS data, GRSP shall at all times uphold the provisions of the XDI.ORG I-Trust(tm) Contract (see GssAgreements.)
-
Other than in connection with the distribution of dividends or other profits to GRSP's members and shareholders, GRSP will not, and will require that its subcontractors do not, directly or indirectly, show any preference or provide any special consideration to any Registrar or Registrant who meets the accreditation or registration requirements specified in the GSS, including a Registrar owned by a GRSP or in which a GRSP has a beneficial interest. The sole exception shall be during the first six month startup period for a new Global Service. During this period a GRSP may offer Registrars preferential access to a Global Service under the terms negotiated with XDI.ORG in order to provide market incentives for early adopters.
-
All Registrars who meet the accreditation requirements specified in the GSS shall have equal access to the GRS as set forth in GssOpSpecs. The sole exception shall be during the six-month startup period as described above.
-
GRSP and its owners shall not in any way attempt to warehouse I-Names. In addition, GRSP shall not attempt to register I-Names in its own right, except for names designated for operational purposes in compliance with GssPolicies/InamePolicies.
-
Any shareholder, subsidiary, affiliate, or other related entity of GRSP that also operates as a provider of Registrar services shall maintain separate books of account with respect to its Registrar operations separate from those of GRSP.
-
Neither GRSP, nor its shareholders, subsidiaries, affiliates, or other related entities shall have access to user data or proprietary information of a Registrar, except as necessary for Registry management and operations.
-
GRSP will ensure that no user data or proprietary information from any Registrar is disclosed to its affiliates, subsidiaries, or other related entities, except as necessary for registry management and operations.
-
Confidential information about GRSP's business services will not be shared with employees of any Registrar, except (i) as necessary for registry management and operations or (ii) if such information is made available to all Registrars on the same terms and conditions.
-
No member of GRSP's Board of Directors will simultaneously serve on the Board of Directors of a Registrar that obtains GRS services from GRSP.
-
No employee of GRSP will hold a greater than 5% interest, financial or otherwise in a company that obtains GRS services from GRSP.
-
No employee of GRSP will also be an employee of any GRSP subsidiary, affiliate or other related entity that also operates as a Registrar.
-
GRSP will ensure that no user data from or proprietary information of any Registry operated or controlled by GRSP is disclosed to any other Registry operated or controlled by GRSP.
-
GRSP will conduct internal neutrality reviews on a regular basis. In addition, GRSP and XDI.ORG may mutually agree on an independent party ("Neutrality Analyst") that XDI.ORG may hire, at XDI.ORG's expense, to conduct a neutrality review of GRSP, ensuring that GRSP and its owners comply with all the provisions of this Policy. The neutrality review may be conducted as often as once per year. GRSP will provide the Neutrality Analyst with reasonable access to information and records appropriate to complete the review. The results of the review of the Neutrality Analyist will be provided to XDI.ORG and shall be deemed to be confidential and proprietary information of GRSP and its owners.
3. Survivability and Data Escrow
After neutrality and fairness, the next key requirement of the GRS is stability and continuity of the Registry infrastructure.3.1. GRS Survivability Policy
GRSPs MUST use commerically reasonable procedures to backup Global Registry data including daily data backup, weekly off-site escrow updates, and the use of geograpically remote data archival systems. All GRSPs MUST enter into a data escrow agreement with XDI.ORG to provide for reasonably foreseeable eventualities such as termination of business, acquisition of business, or termination of the GRSP relationship.4. Fees
The following policies specify the fee structures, amounts, and payment schedules GRSPs must follow.4.1. GRS Fee Structure Policy
Global Services MUST be classified as either Cost-Based or Fee-Based. Cost-based Services must have a cost-based pricing agreement between each GSP and XDI.ORG. Fee-Based Services must have a fee schedule agreement between each GSP and XDI.ORG.The following V1 Global Services are Cost-Based:
-
Global Personal I-Number Service
-
Global Organizational I-Number Service
-
Global Network I-Number Service
-
Public Authority Service
-
Public Trustee Service
The following V1 Global Services are Fee-Based:
-
Global Personal I-Name Service
-
Global Organizational I-Name Service
For each Global Service, XDI.ORG MUST set the initial wholesale fee and publish it via the XDI.ORG website, XDI.ORG general mailing list, and any other reasonable means of notification to the XDI.ORG Community. Changes to the wholesale fee MUST be announced with at least 30 days notice and published via the same means.
The wholesale fee for a Global Service MUST consist of two components:
-
The aggregate of the Cost-Based Fees or Fee-Based Fees set by the Primary GSP and each Secondary GSP (if any) per their contracts negotiated with XDI.ORG.
-
An XDI.ORG Overhead Fee set by XDI.ORG to cover its reasonable operating expenses and XRI/XDI infrastructure development and support costs.
The initial service term for all V1 Global Services is one year. GRSPs MAY offer service terms of more or less than one year and establish and publish alternative fee schedules for such service terms, so long as the GRSP continues to offer registrations for a standard annual service term at the fee schedules herein.
4.2. Cost-Based Fee Policy
For V1 GSS Cost-Based Services, a GRSP MUST charge a Service Fee no greater than the GSP's cost of providing such services plus ten percent (10%). Such costs MUST be supported by commercially reasonable documentation and methodology.In the startup period for a new Cost-Based Global Service (the first service term following commencement of the service), a Cost-Based Service fee MAY be estimated by a GRSP. Any overages or underages after the conclusion of the first service term MAY be reflected by an adjustment to the Cost-Based Service fee for subsequent service terms.
4.3. V1 GSS Fee Schedules
Following are the Primary GSP fee schedules negotiated between XDI.ORG and Cordance for the V1 GSS Fee-Based Services. These schedules represent the maximum fees Cordance as the Primary GSP may charge; Cordance at its sole discretion may charge a fee lower than this maximum amount.These fee schedules are based upon the total cumulative registrations existing on January 1 of each year following the commencement of the service. The total cumulative registrations consist of the total registrations less the aggregate of: (a) all deregistrations, and (b) any registrations for which fees payable are more than thirty (30) days in arrears.
All fees are in U.S. Dollars.
4.3.1. Global Personal I-Name Service
| Total Cumulative Registrations | Annual Maximum Primary GRSP Fee per Registration |
| Less than 5 Million | $5.40 |
| 5-Less than 10 Million | $4.60 |
| 10-Less than 15 Million | $4.20 |
| 15-20 Million | $3.80 |
| Over 20 Million | $3.40 |
4.3.2. Global Organizational I-Name Service
| Total Cumulative Registrations | Annual Maximum Primary GRSP Fee per Registration |
| Less than 1 Million | $22.00 |
| 1-Less than 3 Million | $19.50 |
| 3-Less than 5 Million | $17.50 |
| 5-10 Million | $15.50 |
| Over 10 million | $13.50 |
5. Registrar Support
Primary GRSPs must provide support on the highly technical and administratively complex issues that may arise between the GRS and Registrars. Support to Registrants must be provided by Registrars.5.1. Technical Support Policy
A Primary GRSP MUST provide Registrars with a Web portal for Web-based self-help services, including, frequently asked questions, knowledgebases, white papers, downloads of GRS client software, and support for email messaging.In addition, a Primary GRSP MUST provide Registrars with email-based and telephone-based Help Desk support at hours of operation that reasonably accommodate Registrar's support needs.
A Primary GRSP MAY provide Registrars with fee-based consulting services as a supplement to the above forms of technical support.
5.2. Help Desk Support Policy
The Help Desk MUST provide two tiers of support as defined below.5.2.1. Tier 1 Support
Email or telephone support to Registrars who normally are calling for help with customer XRI problems and such other issues such as GRS implementation or billing and collection. Problems that can't be resolved at Tier 1 are escalated to Tier 2.5.2.2. Tier 2 Support
Email or telephone provided by members of the GRSP technical support team, who are functional experts in all aspects of XRI registration. In addition to resolving escalated Tier 1 problems with XRP implementation and billing and collection, Tier 2 staff provides technical support in system tuning and workload processing.5.3. Escalation Policy
GRSPs MUST implement the following escalation procedures and timelines for elevating problems either to functional experts or to management for resolution if they not resolved within the escalation-policy time limits.| Level | Description | Escalation Policy | Notification |
| I | Catastrophic outage affecting overall Registry operations | Data-center manager escalates to GRSP management and Disaster-Recovery Team if not resolved in 15 minutes | Web portal and e-mail notifications to all Registrars within 15 minutes; updates every 30 minutes |
| II | Systems outage affecting one or two Registrar sessions but not the entire system | Systems engineer escalates to data-center manager if not resolved in one hour | Web-portal notification to all registrars; hourly updates |
| III | Technical questions | Help Desk customer-support specialist escalates to the systems engineer if not resolved in two hours | Hourly updates to registrar via e-mail |
| IV | Basic questions | Help Desk customer-support specialist escalates to the systems engineer if not resolved within four hours | Hourly updates to registrar via e-mail |
5.4. Planned Outage Notification Policy
The Web portal provided by a Primary GRSP MUST include a notice to Registrars of planned outages for database maintenance or installation of software upgrades, and notice MUST also be sent via email to all subscribed Registrars. Except in the case of emergency upgrades, notification MUST be posted 30 days prior to the event and repeated seven days and again two days prior to the scheduled event.5.5. Operational Test and Evaluation Support Policy
A Primary GRSP MUST establish an operational test-and-evaluation facility that will be available for registrars to test their GRS client system using the Registry OT&E specifications (see GssOpSpecs.) This facility MUST include technical support for OT&E testing.Once each new Registrar is satisfied that its system is compatible with the GRS system, it will schedule a formal acceptance test that will be monitored by a GRSP system engineer. After a Registrar has passed the acceptance test, the GRSP will issue its user ID, passwords, and digital certificates, and the Registrar can begin operations.
6. Registry Reporting
Accurate reporting on GRS operations is vital for monitoring the health and stability of XDI.ORG infrastructure. The policies in this section govern the reports GRSPs are required to produce for XDI.ORG.6.1. GRSP Reporting Policy
A Primary GRSP MUST provide, at a minimum, the following Public Registry Report and Confidential Registrar Report to XDI.ORG each calendar quarter. XDI.ORG MAY release the aggregate data for all Registrars in the Confidential Registrar Report immediately however XDI.ORG MUST use reasonable commercial efforts to preserve the confidentiality of the per-Registrar information reported in Confidential Registrar Report until three months after the end of the quarter to which the report relates.Technical details of report formats and delivery mechanisms are specified in GssReports.
6.1.1. Public Registry Report
-
Accredited Registrar Status. State the number of Registrars that have received accreditation status from the Primary GRSP at the end of the reporting quarter, grouped into the following three status categories:
-
Operational Status represents Registrars who have completed OT&E and all necessary legal agreements and have been authorized access into the GRS for processing registrations. It should be noted that Operational Registrars are not listed on the XDI.ORG web site until they specifically request to be listed. This means that a Registrar may be operational from the point of view of the GRSP but not listed on the XDI.ORG website.
-
Pre-Launch Status represents Registrars who have completed OT&E but must still complete the legal agreements or other final preparations necessary to receive the final authorization from the GRSP to commence service.
-
OT&E Status represents Registrars who have received a password to access the Registry operational test and evaluation (OT&E) environment. The OT&E environment is provided to allow registrars to develop and test their systems with the GRS.
-
Application Status represents Registrars who have been sent information regarding the Registry and begun the Registrar Application process, but have not yet entered the OT&E stage.
-
Service Level Agreement Performance. Compare Service Level Agreement ("SLA") requirements with actual performance measures for each month in the reporting quarter.
-
Completed System Software Releases. State significant releases that have occurred since the last report, including:
-
Release Name
-
Features
-
Target Date
-
Complete Date
-
Monthly Growth Trends. Tabulate the total transactions per month and the monthly growth trend in total GRS transactions in the categories below:
-
Write
-
Query
-
Check
-
Failed
-
Daily Transaction Range. Tabulate the number of total daily transactions. The range of transaction volume should be shown for each month along with the average daily transaction volume.
-
Geographical Distribution of Registrations. Tabulate the number and percent of total and new registrations in the GRS broken down by geographical location (country code) as of the end of the current reporting period.
6.1.2. Confidential Registrar Report
-
Global I-Name Registrations Per Registrar. For each Operational Registrar and for each month-end in the reporting period, state the number of Global Personal I-Name and Global Organizational I-Name registrations in the following categories:
-
Beginning registrations (Active, Suspended, Terminated, Expired).
-
Renewed active registrations.
-
New active registrations.
-
Released registrations.
-
Suspended registrations.
-
Terminated registrations.
-
Expired registrations.
-
Reactivated registrations (from those previously Suspended, Terminated, or Expired)
-
Outgoing registration transfers.
-
Incoming registration transfers.
-
Ending registrations (Active, Suspended, Terminated, Expired).
-
Global I-Number Registrations Per Registrar. The same report as above except for I-Numbers.
The Confidential Registrar Report MUST reconcile as follows:
Beginning + New – Released – Suspended – Terminated – Expired + Reactivated – Outgoing transfers + Incoming transfers = Ending
