Generic Top-Level Domain (gTLD) Registry Agreements

gTLD Registry Agreements establish the rights, duties, liabilities, and obligations ICANN requires of registry operators to run gTLDs.

本内容仅提供以下语言版本

  • English

.POST Agreement Appendix S

.POST Agreement Appendix S
  ICANN Logo

.POST Agreement Appendix S

(11 December 2009)


Part I - .POST Charter

The .POST Sponsored TLD was proposed by the Universal Postal Union ((hereinafter the “UPU” or “Sponsor”) to serve the needs of global postal community, including the provision of postal services to citizens of the UPU member countries (hereinafter the “Sponsored Community”, as defined in Part III of this Appendix). The .POST Sponsored TLD (hereinafter the “.POST sTLD”) shall be managed in conformity with the relevant provisions of the UPU for the .POST sTLD, including but not limited to the UPU Acts and any other decisions, policies, regulations and rules of procedure adopted by the UPU and applicable to the .POST sTLD, taking into account the provisions contained in this charter (hereinafter the “Charter”).

Part II - Delegated Authority

The following areas of responsibility for development of policies for the .POST sTLD are delegated to the Sponsor, provided the other provisions of the .POST Sponsored TLD Agreement, including any Appendices and amendments thereto (hereinafter referred to as the “.POST sTLD Agreement”) are complied with:

  • Without prejudice to the relevant provisions of the UPU Acts and any other decisions, policies, regulations and rules of procedure adopted by the UPU for the .POST sTLD, establishment and implementation of policies and practices which are not inconsistent with the .POST sTLD Agreement, ICANN Temporary Specifications and Policies or Consensus Policies;
  • Establishment of naming conventions to be used in the .POST sTLD;
  • Restrictions on what types of entities or individuals may register domain names (which need not be uniform for all names within the .POST sTLD), provided the scope of the Charter is not exceeded;
  • Restrictions on how registered names may be used (which need not be uniform for all names within the .POST sTLD), provided the scope of the Charter is not exceeded;
  • The eligibility and name selection process to be performed by the Sponsor;
  • Mechanism for enforcement of policies, including procedures for the suspension, revocation, and/or reallocation of registrations;
  • Mechanisms for the resolution of domain name disputes;
  • Pricing and terms of agreement for Registry Services;
  • Selection of Registry Operator;
  • Selection of Escrow Agent;
  • Functional and performance specifications for Registry Services other than those specified in Appendix 7 of the .POST sTLD Agreement;
  • Selection of ICANN Accredited Registrars;
  • Approval of terms of services involving Sponsor, Registry Operator, Registrars and registrants;
  • Practices and performance of ICANN-Accredited Registrars selected by the Sponsor with respect to registered names and their registration;
  • Uses and practices by registrants with respect to registered names;
  • Procedures and schedule for the start-up of the .POST sTLD;
  • Consistent with any condition under which a Registry Service has been approved, management responsibility for all Registry Services and products, including but not limited to:
    • Variations, modifications, or extensions of Registry Services that do not represent material changes to a previously approved Registry Service;
    • Changes to policies and restrictions associated with or necessitated by approved Registry Services (e.g. changes to style guides) as outlined in Clauses 6, 7 and 8 below;
    • Pricing;
    • Promotions and promotional products, packaging or pricing;
    • Branding, naming, or other marketing activity;
    • Modification of deployment timelines, rollout plans, and implementation details for approved Registry Services;
    • Withdrawal and suspension of all but basic Registry Services (second level registrations), provided, however, that obligations with registrants existing at the time of the withdrawal or suspension are honored;
    • Provisions for publication of registry and registrar data.

Part III - Description of the .POST sTLD Sponsored Community

The .POST sTLD is intended to serve the needs of the Sponsored Community, whose membership includes:

  • the Universal Postal Union, its permanent bodies and its member countries;
  • the Designated Operator(s) (DOs) of the UPU member countries, as defined in the UPU Acts;
  • the Restricted Unions, as defined in the UPU Acts;
  • Postal operators other than DOs, as authorized by the UPU;
  • Postal partners representing a vast array of commercial organizations that support the provision of postal services, as authorized by the UPU. Postal partners could include but not be limited to:
    • communications partners providing value to the postal value chain, such as hybrid mail vendors offering mail design, printing and preparation services, direct marketing vendors that support the creation of direct mail campaigns, and others;
    • logistics partners providing mail and parcel logistics and support services for the postal industry;
    • suppliers, i.e. vendors specializing in the provision of equipment and services required for the smooth operation of postal operations;
    • payment partners, i.e. vendors providing financial services in support of the postal community;
    • technology partners, i.e. vendors providing technological services in support of the postal community;
    • other postal communities, i.e. representative bodies and associations that represent specialized groups of interest in the postal sector; or
    • educational institutions with postal service functions, which may be any organization that provides training and education to members of the postal community;

The Sponsor may extend or amend the description of the Sponsored Community, in conformity with the relevant provisions of the .POST sTLD Agreement and the Charter.

Part IV – Start-Up Plan

The start-up plan, which consists of a multiphase process whose implementation is to be ensured by the Sponsor, is intended to create a stable and effective registration process for the benefit of the Sponsored Community. The establishment and implementation of the start-up plan may involve the input of the Sponsored Community, with the intention of having the .POST sTLD in the root and operational as soon as practicable.

For this purpose, the Sponsor shall, as soon as reasonably possible, procure a back-end Registry Operator according to the relevant procurement principles and rules defined for the UPU (including but not limited to the UPU Financial Regulations and the UPU Rules on Financial Administration).

Accordingly, the Sponsor shall ensure the establishment and implementation of the start-up plan by the Registry Operator, in accordance with the relevant provisions of the UPU Acts and any other decisions, policies, regulations and rules of procedure adopted by the UPU for the .POST sTLD. Notwithstanding the foregoing, the start-up plan indicated below may be subject to further adjustments in its estimated timeframes and phases, at the discretion of the Sponsor:

#

Phase

Estimated Start/End Timeframe

Comment

0

Policy Development

Started/ongoing

The Sponsor has setup a policy development group to develop the necessary domain management policies.

A

Signing of the Agreement

A

To be signed between the Sponsor and ICANN.

1a

Procure back-end Registry Operator

A – A+90

The Sponsor will follow its formal procurement process for a back-end Registry Operator once the .POST sTLD Agreement has been signed.

1b

Procure Escrow Agent

A – A+90

The Sponsor will follow its formal procurement process for an Escrow Agent once the .POST sTLD Agreement has been signed.

2

Selection of accredited Registrars

A+90 –

Following selection of the Registry Operator, Registrars shall be selected, and the respective Registrar agreements created and published.

3

Pre-registration pilot phases

A+90 – C+180

This phase will aim to authenticate entities allowed to register .POST domain names according to the criteria defined in the domain management policies. No domain name shall be registered at this stage: applicants will only apply for a domain so that their eligibility may be checked. Thereafter, they will be introduced into a database and be given a token/number allowing them to register the domain during the limited pre-launch phase.

 

This pilot phase will be limited to a small number of countries from different regions. It will allow for testing of the registration/authentication processes put in place and give time to make the necessary adjustments.

4

Operational test and evaluation

A+120 – A+180

Sponsor shall ensure that the Registry Operator undertakes comprehensive testing of the registry system and registration procedures (including interfaces with Registrars).

C

Commencement of Registrations

A+180

Milestone

5

Sunrise

C – C+90

Owners of trademarks within the Sponsored Community may register a domain name containing the owned mark.

6

Limited pre-launch

C+90 – C+210

A period during which only the entities that have been pre-authenticated will be permitted to register a .POST domain name.

7

Full operation

C+210 –

Registration open to all entities that meet the criteria defined in the .POST domain management policies established by the Sponsor.

Part V – Selection of ICANN Accredited Registrars

Subject to the Sponsor’s compliance with the .POST sTLD Agreement, any Temporary Specifications or Policies or Consensus Policies as defined therein, as well as the specific provisions contained in Part VI below, and provided the scope of the Charter is not exceeded:

A. The Sponsor has not established a minimum or maximum number of Registrars that will be selected for the .POST sTLD. The Sponsor will accept applications from any Registrar and will enter into agreements with Registrars only after due review of applications in the form it specifies and makes public from time to time.

B. The Sponsor will select from among Registrars considering, among other factors, the following characteristics in the group of authorized Registrars:

1. Recognition of the specific aspects of the Sponsored Community to be supported by the .POST sTLD and a willingness to participate in that spirit, as well as to accept and proactively follow the Sponsor’s mission and objectives for the Sponsored Community;

2. Thorough understanding of the principles and goals underlying .POST sTLD policies, including without limitation the domain name management policy and ability to provide Eligibility and Name-Selection Services (ENS) Services;

3. Demonstrated familiarity with the needs of the Sponsored Community in the language(s) and region(s) served by the Registrar, and established modes for reflecting these needs in the provision of registration services;

4. Dedicated willingness and ability to propagate and enforce .POST sTLD policies in an observant and diligent manner and in accordance with policies and procedures prescribed by Sponsor;

5. Broad geographic distribution and demonstrated ability to deal with language diversity;

6. Established collaborative contact with legal entities, governments, statutory bodies, and other interested stakeholders of the .POST sTLD community (as defined in Part III above) in the language and geographical region or sector served by the Registrar;

7. Dedicated willingness and ability to act together with the Sponsored Community in the processing of registration requests.

8. Established business relationships with substantial numbers (proportionate to the size of the Registrar) of stakeholders in the geographical region(s) or Sponsored Community to be served by the Registrar;

9. Demonstrated willingness and ability to publicize and market the .POST sTLD, to follow all .POST sTLD marketing guidelines, and to develop and use .POST sTLD marketing materials as appropriate, as reflected by a minimum committed marketing budget of an amount proportionate to the size of the Registrar;

10. Demonstration that sufficient staff resources are available and able to interface with automated and manual elements of the .POST sTLD registry process and a willingness to implement modifications and revisions reasonably deemed by the Sponsor or, at the discretion of the Sponsor, the Registry Operator, to be required based on the characteristics and functions of the .POST sTLD;

11. The existence of proven systems designed to avoid submission of unqualified or incomplete applications that will burden the registry system or make it impossible for the Registry Operator to fulfill its commitments to the Sponsor and to ICANN;

12. The existence of proven systems to avoid transfer disputes among Registrars;

13. Willingness and ability to post and refresh a minimum deposit against which fees will be drawn.

14. Willingness to adhere to a WHOIS compliance review policy on periodic basis, and instigate procedures for investigating claims of registrations that many contain false information.

C. The Sponsor will evaluate and, in its reasonable discretion, render a decision with respect to the selection of each applicant to serve as a Registrar based on, all of the above criteria and will periodically review and, as appropriate, revise its selection of Registrars based on such criteria.

Part VI – Public Whois Specification

Without prejudice to the relevant provisions of the UPU Acts and any other decisions, policies, regulations and rules of procedure adopted by the UPU for the .POST sTLD, subject to the Sponsor’s compliance with the .POST sTLD Agreement and any Temporary Specifications or Policies or Consensus Policies as defined therein and provided the scope of the Charter is not exceeded, the Sponsor shall ensure the implementation of the following public WHOIS specification:

SPECIFICATION

Subject to any future policy regarding WHOIS data adopted by ICANN, domain name registrants will be required to provide correct contact information and, as permitted by the UPU Acts, by any other decisions, policies, regulations and rules of procedure adopted by the UPU for the .POST sTLD or by applicable law, consent to selected information being made public for legitimate purposes.

A participating Registrar, at the Registrar’s expense, will be required to provide those wishing to query the WHOIS database (other than for marketing purposes or other purposes contrary to the .POST sTLD policy) with access to complete and up-to-date data for each registered domain name record (subject to applicable privacy policies) including, but not limited to the following:

  • Domain name and the TLD in which the domain name is registered;
  • Status of the domain name, e.g., "on hold" or "pending delete";
  • Registrant's name and postal address;
  • Administrative/technical contacts' name, postal address, e-mail address, telephone number and (if any) facsimile number;
  • Original registration date, expiration date and date on which the database was last updated;
  • Internet Protocol addresses and corresponding names of primary and secondary;
  • Name servers for the domain name; and
  • Registrar's identification information.

In order to assist complainants under the UDRP to determine whether a pattern of "bad faith" has been demonstrated by a particular registrant, the information set forth above will be available on a publicly accessible database, subject to applicable privacy policies, which will be searchable by domain name, registrant's name, registrant's postal address, contacts' names, Registrars Contact IDs and Internet Protocol address without arbitrary limit. In order to provide an effective WHOIS database, Boolean search capabilities may be offered.

Registrars shall be required to participate in the operation of a cross-registry WHOIS database, which will provide searching capabilities and access to all information concerning domain name registrations regardless of which TLD the domain name is registered in or which the Registrar processed the domain name application.

The Sponsor shall ensure that the Registry Operator requires Registrars to adhere to a compliance review policy. As part of that policy, each Registrar shall be required to designate a contact point to which evidence of false or fraudulent contact data may be reported. Registrars will institute procedures for investigating claims that registrations may contain false information, and for registrations found to contain false information, requiring their speedy and efficient correction, or otherwise cancellation. Interested third parties may invoke these procedures. The Sponsor shall also ensure that RFC3912-conformant WHOIS services are provided by the Registry Operator. This Appendix is subject to change by agreement of the Sponsor and ICANN during the design process, as well as during the IETF standards process. However, the following sections provide the intended target architecture and initial functionality.

RFC3912-Conformant WHOIS

The standard WHOIS service is intended as a lookup service for registries, registrars, registrants, as well as for other individuals and businesses that wish to query details of domain names or name servers stored in the registry. The standard WHOIS service will provide a central location for all authoritative .post sTLD data. The registry provides a front-end web interface to allow convenient user access to the WHOIS service.

The RFC3912-conformant WHOIS service will be engineered to handle moderate transaction load and be integral to the standard suite of Registry Services. The WHOIS service will return a single response per domain name or name server query. The RFC3912-conformant WHOIS service will conform to the requirements of Appendix 5 and 7.

The RFC3912-conformant service provided by the registry will have the following features:

  • Standard protocol accessible over port 43.
  • Batch-style or near real time updates.
  • Additional fields capability.
  • WHOIS Service Data Elements

WHOIS Service Data Elements

The RFC3912-conformant service will include the following data elements:

  • The name of the domain name registered;
  • The IP addresses of the primary name server and secondary name server(s) of the name registered, if applicable, i.e. name server has a .post name;
  • The corresponding names of those name servers;
  • The identity of the Registrar;
  • The original creation date and term of the registration;
  • The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the domain name registrant;
  • The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the name registered;
  • The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the name registered; and
  • The Maintainer URL (email or website). The maintainer is a person that has been designated by the Registrar for the registration of the domain (for example a reseller, could also depend on the registrant)

Minimum Data Update Frequency

The Sponsor shall ensure that the Registry Operator makes its reasonable efforts to update the data continuously as requests are processed, in a matter of seconds or minutes. The typical update cycle will be 30 seconds but may be different depending on performance considerations. The Sponsor shall equally ensure that the Registry Operator updates records in the WHOIS server no later than 24 hours after the completion of the registration or modification transaction with the Registrar.

Additional Fields Capability

If necessary, the Sponsor may require the Registry Operator to introduce after a 6 to 12-month period of operational stability some additional fields to the list of WHOIS fields. Those fields will be preceded and identified by appropriate tags. Additional fields will not contain any information that could be used to facilitate ENUM applications.

Privacy Capability

The Sponsor may also allow the Registry Operator to introduce the optional ability to associate privacy labels to a record in the Registry Database. These fields would appear in an "additional information" section of the WHOIS data. The maximum number of custom fields allowed per record is yet to be determined. The privacy label capability allows certain data to be associated with an indication of any special disclosure or handling restrictions. This characteristic may be used e.g. to comply with potential regulatory or other telecom subscription related requirements, which mobile operators need to implement in their services.

Query Control - Object Type Control

The following keywords restrict a search to specific object type:

  • Domain: Search only by domain objects. The input string is searched in the Name field.
  • Contact: Search only contact objects. The input string is searched in the ID field.
  • Name server: Search only by name server objects. The input string is searched in the name server field or the IP address field.
  • Registrar: Search only registrar objects. The input string is searched in the Name field. By default, if no object type control is specified, then the Name field of the Domain object is searched.

WHOIS Output Fields

Domain Record:

A WHOIS query that results in domain information will return the following fields from the Domain object and the associated data from host and contact objects. This set of data is also referred to as the Domain Record.

Domain ID Domain Name
Domain Status
Registry Operating Registrar (IANA-assigned identifier)
Registrant, Administrative, Technical and Billing Contact Information including:


Contact ID
Contact Name
Contact Organization
Contact Address, City, State/Province, Geographic location
Contact Postal Code
Contact Phone, Fax, E-mail




Maintainer URL
Names of Name servers associated with this domain
Created by Registrar (IANA-assigned identifier)
Last Updated by Registrar (IANA-assigned identifier)
Last Transferred Date
Additional fields (Registry Operator specified, will be defined later, if required)
Domain Registration Date
Domain Expiration Date
Domain Last Updated Date







Name server Record:
A WHOIS query that results in name server information will return the following. This set of information is referred to as the Name server Record.
Name server ID
Name server name
Currently Associated (true/false)
Name server status
IP addresses associated (if applicable)
Created by Registrar (IANA-assigned identifier)
Registry Operator Registrar (IANA-assigned identifier)
Last Updated by Registrar (IANA-assigned identifier)
Created Date
Last Updated Date
Last Transferred Date
Additional fields












Note: Any additional fields will be Registry Operator specified, to be defined later if required.

Contact Record:
A WHOIS query that results in contact information will return the following. This set of information is referred to as the Contact Record.
Contact ID
Contact Name
Contact Organization
Contact Address, City, State/Province, Geographic location + 3 street fields
Contact Postal Code
Contact Phone, Fax, E-mail
Contact Registration Date
Contact Last Updated Date
Currently Associated
Contact Status Additional fields (Registry Operator specified)
Registry Operator Registrar (IANA-assigned identifier)
Created by Registrar (IANA-assigned identifier)
Last Transferred Date













Registrar Record:
A WHOIS query that results in registrar information will return the following. This set of information is referred to as the Registrar Record.
Registrar ID (conforming to the IANA registrar-ids registry)
Registrar Name
Registrar Status
Registrar Address, City, State/Province, Geographic location
Registrar Postal Code
Registrar Phone, Fax, E-mail
Registrar Administrative Contacts
Registrar Technical Contacts
Registrar Billing Contacts









Sample WHOIS Output

This section provides sample output from the WHOIS server for each type of Registry Object: Domain, Contact, Name server, and Registrar. The output is structured as key/value pairs, which simplifies machine-readability. In the Input section, the quoted string represents the string actually passed to the server in the request packet.

Domain Record:
Input: WHOIS "domain = domainname.post "
Output: Domain ID: AAA-0001
Domain Name: MO.POST
Registry Operator Registrar: REG-01
Domain Status: ACTIVE
Registrant ID: PER-00001
Registrant Name: AHMED ASSAF
Registrant Organization: POSTE MAROC
Registrant Address: RUE DE LA POST
Registrant City: RABAT
Registrant State/Province: MOROCCO
Registrant Geographic location: MO
Registrant Postal Code: N/A
Registrant Phone Number: +212-9876-5432
Registrant Facsimile Number: +212-2345-6789
Registrant Email: AHMED@MO.POST
Admin ID: PER-00002
Admin Name: FRED SMITH
Admin Organization: ROYAL MAIL
Admin Address: 1 HIGH STREET
Admin City: GUILDFORD
Admin State/Province: SURREY
Admin Geographic location: UK
Admin Postal Code: GU1
Admin Phone Number: +44-20-123-4567
Admin Facsimile Number: +44-20-123-4568
Admin Email: FSMITH@GB.POST
Tech ID: PER-00002 Tech Name: FRED SMITH
Tech Organization: ROYAL MAIL
Tech Address: 1 HIGH STREET
Tech City: GUILDFORD
Tech State/Province: SURREY
Tech Geographic location: UK
Tech Postal Code: GU1
Tech Phone Number: +44-20-123-4567
Tech Facsimile Number: +44-20-123-4568
Tech Email: FSMITH@GB.POST
Billing ID: PER-00002
Billing Name: FRED SMITH
Billing Organization: ROYAL MAIL
Billing Address: 1 HIGH STREET
Billing City: GUILDFORD
Billing State/Province: SURREY
Billing Geographic location: UK
Billing Postal Code: GU1
Billing Phone Number: +44-20-123-4567
Billing Facsimile Number: +44-20-123-4568
Billing Email: FSMITH@GB.POST
Name Server: NIC.POST
Name Server: WWW.ICOM.ORG
Maintainer: SPECIALCARE@RESELLER.COM
Created By: REG-02 Updated By: REG-01
Created On: 2002-01-02 Expires On: 2004-01-02
Updated On: 2002-03-02
Transferred On: 2002-03-02






















































Name server Record:
Input: WHOIS "name server nic.gb.post or WHOIS "name server 130.242.24.6"

Output:

Name server ID: HST-1
Name server name: NIC.GB.POST
Currently Associated (true/false):T
Name server status: ACTIVE
IP addresses associated: 130.242.28.6
Registry Operator Registrar: REG-01
Created By: REG-02
Updated By: REG-01
Created On: 2002-01-02
Updated On: 2002-03-02
Transferred On: 2002-03-02
Additional fields (Registry Operator specified, will be defined later, if required)










Contact Record:
Input: WHOIS "contact = PER-00002"

Output:
Contact ID: PER-00002
Name: FRED SMITH
Organization: ROYAL MAIL
Address: 1 HIGH STREET
City: GUILDFORD
State: SURREY
Geographic location: UK
Postal Code: GU1
Phone Number: +44-20-123-4567
Facsimile Number +44-20-123-4568
E-mail: FSMITH@GB.POST
Status: Active
Registry Operator Registrar: REG-01
Created By: REG-01
Created On: 2002-01-02
Updated On: 2002-01-02
Transferred On: 0000-00-00
















Registrar Record:
Input: WHOIS "registrar SAMPLE"

Output:
Registrar ID: REG-01
Registrar Name: SAMPLE
Registrar Status: ACTIVE
Registrar Address 1: 123 Some Street
Registrar Address 2:
Registrar City: Acity
Registrar State/Province: RE
Registrar Geographic location: CC
Registrar Postal Code: 12345
Registrar Phone: +11-11-1111-1111
Registrar Fax: +22-22-2222-2222
Registrar E-mail: jdoe@sample.tld
Admin Contact ID: PER-00003
Tech Contact ID: PER-00004
Billing Contact Name: PER-00005














Part VII – Additional Provisions

ICANN and the Sponsor acknowledge that a criterion included in the application process in which the .POST sTLD was selected, and in the previous TLD application expansion round, was that a new TLD be clearly differentiated from existing TLDs.