RFC 3375

Generic Registry-Registrar Protocol Requirements

📅 published September 2002, from ietf

Generic Registry-Registrar Protocol Requirements 🎀

Okay bestie, so this one is RFC 3375, Generic Registry-Registrar Protocol Requirements ✨. It was written by S. Hollenbeck from Verisign, Inc. It's Informational, dated September 2002, and the header doesn't list any RFCs it obsoletes or updates 🌸

Status of this Memo

This memo is giving information for the Internet community 💅 It doesn't specify an Internet standard of any kind, so nobody's required to implement it. Distribution is unlimited, so share it with your whole group chat 🦋

Copyright (C) The Internet Society (2002). All Rights Reserved. 💜

Abstract

This doc lays out the high-level functional and interface requirements for a client-server protocol that handles registering and managing Internet domain names in shared registries 🌈 It doesn't go into the detailed technical requirements for protocol design. Instead, it focuses on the basic functions and interfaces a protocol needs to support multiple registry and registrar operational models. It's the big-picture vision board, not the wiring diagram 🧚

Conventions Used In This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These are the official requirement-level words, so when you see them in caps, they're doing serious work 🫶

Table of Contents

   1.  Introduction .......................................  2
   1.1 Definitions, Acronyms, and Abbreviations ...........  2
   2.  General Description ................................  4
   2.1 System Perspective .................................  4
   2.2 System Functions ...................................  4
   2.3 User Characteristics ...............................  5
   2.4 Assumptions ........................................  5
   3.  Functional Requirements ............................  5
   3.1 Session Management .................................  6
   3.2 Identification and Authentication ..................  6
   3.3 Transaction Identification .........................  7
   3.4 Object Management ..................................  7
   3.5 Domain Status Indicators ........................... 13
   3.6 Transaction Completion Status ...................... 13
   4.  External Interface Requirements .................... 14
   4.1 User, Hardware, and Software Interfaces ............ 14
   4.2 Communications Interfaces .......................... 14
   5.  Performance Requirements ........................... 14
   6.  Design Constraints ................................. 14
   6.1 Standards Compliance ............................... 14
   6.2 Hardware Limitations ............................... 15
   7.  Service Attributes ................................. 15
   7.1 Reliability ........................................ 15
   7.2 Availability ....................................... 15
   7.3 Scalability ........................................ 16
   7.4 Maintainability .................................... 16
   7.5 Extensibility ...................................... 16
   7.6 Security ........................................... 16
   8.  Other Requirements ................................. 17
   8.1 Database Requirements .............................. 17
   8.2 Operational Requirements ........................... 17
   8.3 Site Adaptation Requirements ....................... 17
   8.4 Data Collection Requirements ....................... 17
   9.  Internationalization Requirements .................. 18
   10. IANA Considerations ................................ 18
   11. Security Considerations ............................ 18
   12. Acknowledgements ................................... 19
   13. References ......................................... 19
   14. Editor's Address ................................... 20
   15. Full Copyright Statement ........................... 21

1. Introduction 🌸

Shared domain name registration systems are a perfect example of why we want one common, generic protocol for registry-registrar interaction 💖 A standard generic protocol lets registrars talk to multiple registries through a single common interface, which cuts down on operational complexity. This document describes the high-level functional and interface requirements for a generic provisioning protocol that works for registry-registrar operations. The detailed technical requirements aren't addressed here 🦋

1.1 Definitions, Acronyms, and Abbreviations 📚

ccTLD: Country Code Top Level Domain. ".us" is an example of a ccTLD 🇺🇸

DNS: Domain Name System 🌐

gTLD: Generic Top Level Domain. ".com" is an example of a gTLD 💅

IANA: Internet Assigned Numbers Authority 🎀

IETF: Internet Engineering Task Force 🧚

IP Address: Either or both IPv4 or IPv6 address. 🌈

IPv4: Internet Protocol version 4 ✨

IPv6: Internet Protocol version 6 ✨

RRP: Registry-Registrar Protocol 🦋

TLD: Top Level Domain. A generic term used to describe both gTLDs and ccTLDs that exist under the top-level root of the domain name hierarchy. It's the umbrella term, bestie 👑

Exclusive Registration System: A domain name registration system in which registry services are limited to a single registrar. Exclusive Registration Systems are either loosely coupled (where the separation between registry and registrar systems is readily evident), or tightly coupled (where that separation is obscure). 💜

Name Space: The range of values that can be assigned within a particular node of the domain name hierarchy. 🍓

Object: A generic term used to describe entities that are created, updated, deleted, and otherwise managed by a generic registry-registrar protocol. 🫶

Registrant: An entity that registers domain names in a registry through the services provided by a registrar. Registrants include individuals, organizations, and corporations. 🙈

Registrar: An entity that provides front-end domain name registration services to registrants, giving them a public interface to registry services. 💅

Registry: An entity that provides back-end domain name registration services to registrars. It manages a central repository of information associated with domain name delegations. A registry is typically responsible for publishing and distributing the zone files used by the Domain Name System 🗂️

Shared Registration System: A domain name registration system in which registry services are shared among multiple independent registrars. Shared Registration Systems require a loose coupling between registrars and a registry. Very group-project energy 🤝

Thick Registry: A registry where all of the information associated with registered entities is stored within the registry repository. That includes both technical information (information needed to produce zone files) and social information (information needed to implement operational, business, or legal practices). Everything lives in one place, no cap 💖

Thin Registry: A registry where all elements of the social information associated with registered entities is distributed between a shared registry and the registrars served by the registry. The social info is split up, so it's a team effort 🌸

Zone: The complete set of information for a particular "pruned" subtree of the domain space. The zone concept is described fully in [RFC1035]. Go read that one if you want the full lore 📖

2. General Description ✨

Knowing how domain name registration systems work gives us the focus we need to list the functional and interface requirements for a protocol that serves them 🎀 This section gives a high-level description of those systems, so you have context for the requirements coming later in the document. Think of it as the setup before the main event 💅

2.1 System Perspective 🦋

A domain name registration system is made up of a protocol plus the software and hardware that lets registrars offer Internet domain name registration services within the name spaces a registry administers. A registration system can be shared among multiple competing registrars. It can also be served by a single registrar that is either tightly or loosely coupled with back-end registry services. The system that provides registration services for the .com, .net, and .org gTLDs is an example of a shared registration system serving multiple competing registrars. The systems that provide registration services for some ccTLDs, plus the .gov and .mil gTLDs, are examples of registration systems served by a single registrar 🌈

2.2 System Functions 🧚

Registrars access a registry through a protocol so they can register objects and perform object management functions. Required functions include session management; object creation, update, renewal, and deletion; object query; and object transfer. That's a whole to-do list, bestie ✅

A registry generates DNS zone files for the name spaces it serves. Those zone files get created and distributed to a series of name servers, which are the foundation of the domain name system 💖

2.3 User Characteristics 💜

Protocol users fall into two broad categories: entities that use protocol client implementations, and entities that use protocol server implementations. An entity can provide both client and server services if it offers intermediate services. A protocol provides a loose coupling between these communicating entities. Client and server, but make it a loose couple 🫶

2.4 Assumptions 🙈

There is one and only one registry that is authoritative for a given name space and zone. That's the golden rule 👑

A registry can be authoritative for more than one name space and zone. Some registry operations can be billable. The impact of a billable operation can be mitigated through the specification of non-billable operations that allow a registrar to make informed decisions before executing billable operations. So the registrar can check things out before spending any money 💸

A registry can choose to implement a subset of the features provided by a generic registry-registrar protocol. A thin registry, for example, might not provide services to register social information. Specifying minimal implementation compliance requirements is therefore an exercise left for a formal protocol definition document that addresses the functional requirements specified here 🎀

A protocol that meets the requirements described here can be called something other than "Generic Registry Registrar Protocol". Name it whatever slaps 💅

The requirements described in this document are not intended to limit the set of objects that can be managed by a generic registry-registrar protocol. No box-checking here, the object list stays open 🌸

3. Functional Requirements 🌟

This section describes the functional requirements for a registry-registrar protocol. Technical requirements that describe how these requirements get met are out of scope for this document 🧚

3.1 Session Management 🔐

[1] The protocol MUST provide services to explicitly establish a client session with a registry server. Sessions don't just happen by vibes, they have to be set up on purpose 💖

[2] In a connection-oriented environment, a server MUST respond to connection attempts with information that identifies the server and the default server protocol version. Introduce yourself at the door, bestie 🚪

[3] The protocol MUST provide services that allow a client to request use of a specific protocol version as part of negotiating a session. Client says "I'd like this version, pls" 🎀

[4] The protocol MUST provide services that allow a server to decline use of a specific protocol version as part of negotiating a session. The server gets to say "not that one" 🙅‍♀️

[5] A session MUST NOT be established if the client and server are unable to reach agreement on the protocol version to be used for the requested session. No agreement, no session. Period 💅

[6] The protocol MUST provide services to explicitly end an established session. Clean exits only, babe 👋

[7] The protocol MUST provide services that provide transactional atomicity, consistency, isolation, and durability in the advent of session management failures. Even when the session crashes, the data stays ACID-iconic 👑

[8] The protocol MUST provide services to confirm that a transaction has been completed if a session is aborted prematurely. If the session ghosts you mid-transaction, you can still check whether it went through 🫶

3.2 Identification and Authentication 🔐

okay so [1] the protocol (or another layered protocol) MUST provide services to identify registrar clients and registry servers before granting access to other protocol services. no ID, no entry, bestie 🫶

[2] the protocol (or another layered protocol) MUST provide services to authenticate registrar clients and registry servers before granting access to other protocol services. so not only do you have to say who you are, you have to prove it 💅

[3] the protocol (or another layered protocol) MUST provide services to negotiate an authentication mechanism acceptable to both client and server. both sides gotta agree on how the ID check happens, so nobody's left out of the vibe 🤝

3.3 Transaction Identification 🧾

[1] registry operations that create, modify, or delete objects MUST be associated with a registry-unique identifier. the protocol MUST allow each transaction to be identified in a permanent and globally unique manner to facilitate temporal ordering and state management services. every single change gets its own forever-unique receipt, so the timeline stays iconic 📜✨

3.4 Object Management 📦

this section is all about object management: identification, registration, association, update, transfer, renewal, deletion, and query. it's the whole life story of a domain, a name server, or a contact, and it's giving main character energy 🎀

3.4.1 Object Identification 🪪

some objects, like name servers and contacts, are useful in more than one registry. but keeping separate copies of the same object info in lots of registries can lead to inconsistencies, and those can cause real problems for the Internet 😭 for example, changing a name server name in one registry but not in a second registry that uses that server for domain name delegation can produce unexpected DNS query results. yikes 💀

[1] the protocol MUST provide services to associate an object identifier with every object. everything gets an ID 🆔

[2] object identifiers MUST be globally unique. no twins allowed 👯‍♀️

[3] an object's identifier MUST NOT change during the lifetime of the object in a particular repository, even if administrative control of the object changes over time. the ID stays the same even when the hands on the object change 🫡

[4] an object identifier MUST contain information that unambiguously identifies the object. no vague IDs, we want clarity ✨

[5] object identifier format specified by the protocol SHOULD be easily parsed and understood by humans. it's lowkey recommended that people can read these IDs without a decoder ring 🧚

[6] an object's identifier MUST be generated and stored when an object is created. born with an ID, no exceptions 🍓

3.4.2 Object Registration 📝

[1] the protocol MUST provide services to register Internet domain names. domain names get registered here, obviously 🌈

[2] the protocol MUST permit a starting and ending time for a domain name registration to be negotiated. this lets a registry set policies allowing a range of registration validity periods (the start and end points in time during which one normally assumes that an object will be active), and lets registrars pick a period for each registration they submit from within the valid range, based on out-of-band negotiation between the registrar and the registrant. registries SHOULD be allowed to accept indefinitely valid registrations if the policy that they are implementing permits, and to specify a default validity period if one is not selected by a registrar. registries MUST be allowed to specify minimal validity periods consistent with prevailing or preferred practices for fee-for-service recovery. the protocol MUST provide features to ensure that both registry and registrar have a mutual understanding of the validity period at the conclusion of a successful registration event. so both sides end up on the same page about how long the registration lasts 📅💖

[3] the protocol MUST provide services to register name servers. name server registration MUST NOT be limited to a specific period of time. name servers MUST be registered with a valid IPv4 or IPv6 address when a "glue record" is required for delegation. a name server MAY be registered with multiple IP addresses. multiple name servers using distinct server names MAY share an IP address. so many options, so little drama 🦋

[4] the protocol MUST provide services to manage delegation of zone authority. names of name servers MUST NOT be required to be tied to the name of the zone(s) for which the server is authoritative. the server's name doesn't have to match the zone it's in charge of 🙅‍♀️

[5] the protocol MUST provide services to register social information describing human and organizational entities. registration of social information MUST NOT be limited to a specific period of time. social information MAY include a name (individual name, organization name, or both), address (including street address, city, state or province (if applicable), postal code, and country), voice telephone number, email address, and facsimile telephone number. the people and orgs behind the objects get their own little profile 💌

[6] protocol services to register an object MUST be available to all authorized registrars. every authorized registrar gets access, no gatekeeping 🌸

3.4.3 Object Association 🔗

[1] the protocol MUST provide services to associate name servers with domain names to delegate authority for zones. a domain name MAY have multiple authoritative name servers. name servers MAY be authoritative for multiple zones. it's a whole web of friendships 🕸️💜

[2] the protocol MUST provide services to associate IP addresses with name servers. a name server MAY have multiple IP addresses. an IP address MAY be associated with multiple name server registrations. lots of flexibility here, slay 💅

[3] the protocol MUST provide services to associate social information with other objects. social information associations MUST be identified by type. "Registrant" is an example social information type that might be associated with an object such as a domain name. every connection needs a label so we know what it means 🏷️

[4] the protocol MUST provide services to associate object management capabilities on a per-registrar basis. each registrar gets its own set of powers 👑

[5] some managed objects represent shared resources that might be referenced by multiple registrars. the protocol MUST provide services that allow a registrar to associate an existing shared resource object with other registered objects sponsored by a second registrar. for example, authority for the example.tld zone (example.tld domain object managed by registrar X) and authority for the test.tld zone (test.tld domain object managed by registrar Y) might be delegated to server ns1.example.tld (managed by registrar X). registrar X maintains administrative control over domain object example.tld and server object ns1.example.tld, and registrar Y maintains administrative control over domain object test.tld. registrar Y does not have administrative control over server object ns1.example.tld. so the server is shared, but the boss of the server is still registrar X 🫶🔥

3.4.4 Object Update ✏️

[1] the protocol MUST provide services to update information associated with registered Internet domain names. domain info can get a glow-up 💖

[2] the protocol MUST provide services to update information associated with registered name servers. name servers get glow-ups too ✨

[3] the protocol MUST provide services to update social information associated with registered human and organizational entities. the contact profiles can be updated as well 🎀

[4] the protocol MUST provide services to limit requests to update a registered object to the registrar that currently sponsors the registered object. only the sponsoring registrar gets to edit, no uninvited guests 🙅‍♀️

[5] the protocol MUST provide services to explicitly reject unauthorized attempts to update a registered object. if you're not allowed, you get a clear no 🚫

3.4.5 Object Transfer 🚚

[1] the protocol MUST provide services to transfer domain names among authorized registrars. name servers registered in a domain being transferred MUST be transferred along with the domain itself. for example, name servers "ns1.example.tld" and "ns2.example.tld" MUST be implicitly transferred when domain "example.tld" is transferred. the domain and its name servers move together, like a package deal 📦💕

[2] the protocol MUST provide services to describe all objects, including associated objects, that are transferred as a result of an object transfer. everything that moves gets listed 📋

[3] the protocol MUST provide services to transfer social information objects among authorized registrars. the contact info moves too 💌

[4] protocol transfer requests MUST be initiated by the registrar who wishes to become the new administrator of an object. the new registrar is the one who asks for the move 🙋‍♀️

[5] the protocol MUST provide services to confirm registrar authorization to transfer an object. the transfer gets a permission check first 🔐

[6] the protocol MUST provide services that allow the requesting registrar to cancel a requested object transfer before the request has been approved or rejected by the original sponsoring registrar. requests to cancel the transfer of registered objects MUST be limited to the registrar that requested transfer of the registered object. unauthorized attempts to cancel the transfer of a registered object MUST be explicitly rejected. changed your mind? you can cancel, but only if you're the one who asked, and anyone else gets an explicit no 🙅‍♀️💀

[7] the protocol MUST provide services that allow the original sponsoring registrar to approve or reject a requested object transfer. requests to approve or reject the transfer of registered objects MUST be limited to the registrar that currently sponsors the registered object. unauthorized attempts to approve or reject the transfer of a registered object MUST be explicitly rejected. the current sponsor is the gatekeeper for transfers, and everyone else gets a firm no 🚪

[8] the protocol MUST provide services that allow both the original sponsoring registrar and the potential new registrar to monitor the status of both pending and completed transfer requests. both sides can check on the status, so nobody's left hanging 👀

[9] transfer of an object MAY extend the object's registration period. if an object's registration period will be extended as the result of a transfer, the new expiration date and time MUST be returned after successful completion of a transfer request. if the transfer adds time, you get the new end date back 📅🌟

[10] requests to initiate the transfer of a registered object MUST be available to all authorized registrars. any authorized registrar can ask for a transfer 🌷

[11] registrars might become non-functional and unable to respond to transfer requests. it might be necessary for one registrar to assume management responsibility for the objects associated with another registrar in the event of registrar failure. the protocol MUST NOT restrict the ability to transfer objects in the event of registrar failure. so if a registrar goes down, the protocol doesn't block the transfer, which is kind of a safety net 🧸🫶

3.4.6 Object Renewal/Extension ⏳

[1] the protocol MUST provide services to renew or extend the validity period of registered domain names. if applicable, the new expiration date and time MUST be returned after successful completion of a request to renew or extend the validity period. renewals get the new end date too 🎂

[2] requests to renew or extend the validity period of a registered object MUST be limited to the registrar that currently sponsors the registered object. unauthorized attempts to renew or extend the validity period of a registered object MUST be explicitly rejected. only the sponsor can extend the timeline, and everyone else gets a clear no 🙅‍♀️

3.4.7 Object Deletion 🗑️

[1] the protocol MUST provide services to remove a domain name from the registry. domains can be deleted 🫧

[2] the protocol MUST provide services to remove a name server from the registry. name servers can be removed too 🌙

[3] the protocol MUST provide services to remove a social information object from the registry. contact profiles can go as well 🥀

[4] requests to remove a registered object MUST be limited to the registrar that currently sponsors the registered object. unauthorized attempts to remove a registered object MUST be explicitly rejected. only the sponsoring registrar can delete, and anyone else gets an explicit no 🚫💅

3.4.8 Object Existence Query 🔍

this section covers a lightweight query whose only job is to check if an object exists in a registry. quick, simple, no drama 🦋

[1] the protocol MUST provide services to determine if a domain name exists in the registry. domain names MUST be searchable by fully qualified name. so you search by the full name, like a proper bestie 🔎

[2] the protocol MUST provide services to determine if a name server exists in the registry. name servers MUST be searchable by fully qualified name. same deal for name servers 🌷

[3] the protocol MUST provide services to determine if a social information object exists in the registry. social information MUST be searchable by a registry-unique identifier. contacts get looked up by their unique ID instead 🪪

[4] a query to determine if an object exists in the registry MUST return only a positive or negative response so that server software that responds to this query can be optimized for speed. just a yes or a no, which keeps the server speedy and efficient ⚡💜

[5] requests to determine the existence of a registered object MUST be available to all authorized registrars. every authorized registrar can ask if an object exists 🌈

3.4.9 Object Information Query 🔍

okay so this section is all about the query mechanism, the thing that lets you pull up everything about an object sitting in a registry 💖 it's giving "tell me everything about this domain, bestie" energy.

[1] The protocol MUST provide services to retrieve information describing a domain name from the registry 📦 The info that comes back MUST include the identifier of the current sponsoring registrar, the identifier of the registrar that originally registered the domain, the creation date and time, the expiration date and time (if any), the date and time of the last successful update (if any), the identifier of the registrar that performed the last update, the date and time of last completed transfer (if any), the current status of the domain, authorization information, identifiers describing social information associated with the domain, and the subordinate name servers registered in the domain. Authorization information MUST only be returned to the current sponsoring registrar 🔒 nobody else gets to peek at that, periodt.

[2] The protocol MUST provide services to retrieve information describing a name server from the registry 🖥️ The returned info MUST include the identifier of the current sponsoring registrar, the identifier of the registrar that originally registered the name server, the creation date and time, the date and time of the last successful update (if any), the identifier of the registrar that performed the last update, the date and time of last completed transfer (if any), and the IP addresses currently associated with the name server ✨

[3] The protocol MUST provide services to retrieve social information from the registry 🫶 The returned info MUST include identification attributes (which MAY include name, address, telephone numbers, and email address), the identifier of the registrar that originally registered the information, the creation date and time, the date and time of the last successful update (if any), the identifier of the registrar that performed the last update, the date and time of last completed transfer (if any), and authorization information. Authorization information MUST only be returned to the current sponsoring registrar 🔒 same energy as before, lowkey iconic.

[4] The protocol MUST provide services to identify all associated object references 🧩 think name servers tied to domains (including delegations and hierarchical relationships) and contacts tied to domains. This information MUST be visible if the object associations have an impact on the success or failure of protocol operations 👀 if the connection matters for whether something works, it has to be out in the open.

[5] Requests to retrieve information describing a registered object MAY be granted by the registrar that currently sponsors the registered object 🌸 Unauthorized attempts to retrieve information describing a registered object MUST be explicitly rejected 🚫 no sneaky access, full stop.

3.5 Domain Status Indicators 🚦

[1] The protocol MUST provide status indicators that identify the operational state of a domain name 💅 Indicators MAY be provided for a few vibes: a newly created state (registered but not yet showing up in a zone 🍼), a normal active state (can be modified and published in a zone ✅), an inactive state (can be modified but not published in a zone, because it has no authoritative name servers 💤), a hold state (can not be modified and is not published in a zone ⏸️), a lock state (can not be modified and is published in a zone 🔐), a pending transfer state 🧳, and a pending removal state 🗑️.

[2] If provided, protocol indicators for hold and lock status MUST allow independent setting by both registry and registrar 🤝 each side gets its own control, no stepping on toes.

[3] A domain MAY have multiple statuses at any given time 🌈 Some statuses MAY be mutually exclusive, so they can't all hang out together 🙅‍♀️

3.6 Transaction Completion Status ✅

[1] The protocol MUST provide services that unambiguously note the success or failure of every transaction 💯 Individual success and error conditions MUST be noted distinctly, so nobody has to guess what happened 🫠

4. External Interface Requirements 🎀

okay so external interfaces are the spots where your system meets the outside world 🌍 the entities that talk to it. The interesting areas are user interfaces, hardware interfaces, software interfaces, and communications interfaces 🔌

4.1 User, Hardware, and Software Interfaces 🖱️

[1] The protocol MUST define a wire format for data exchange 📡 It is NOT meant to be an application design for user, hardware, or software interfaces. The point is that any application able to create the same bits on the wire, and to maintain the image of the same integrity constraints, is a valid implementation of the protocol 💖 the bits are the boss, not the UI.

4.2 Communications Interfaces 📞

[1] Registries, registrars, and registrants interact using a wide spectrum of communications interfaces built on multiple protocols 🌐 including transport layer protocols like TCP and application layer protocols like SMTP. The protocol MUST only be run over IETF approved protocols that feature congestion control, such as TCP and SCTP 🚦 no unapproved transports allowed, bestie.

5. Performance Requirements ⚡

[1] Run-time performance is an absolutely critical aspect of protocol usability 🔥 Performance depends heavily on the hardware and software architecture that implements a protocol, but protocol features can have a direct impact on how well that architecture performs 🏎️ The protocol MUST be usable in both high volume and low volume operating environments 📈📉 it has to slay in both.

6. Design Constraints 🧱

okay so when you're balancing protocol design decisions, there's more to think about than just the functional and interface stuff 🧠 This section covers extra factors that might affect the design, like standards compliance and hardware limitations.

6.1 Standards Compliance 📜

[1] The protocol MUST conform to current IETF standards 🏛️ Standards for domain and host name syntax, IP address syntax, security, and transport are especially relevant. Emerging standards for the Domain Name System MUST be considered as they approach maturity 👀 keep an eye on what's coming.

[2] The protocol MUST NOT reinvent services offered by lower layer protocol standards 🙅‍♀️ For example, if you need reliability, pick a transport that already provides it, rather than using a non-reliable transport and making the protocol itself do retransmission to get reliability 🔁 don't do the same job twice, bestie.

6.2 Hardware Limitations 🖥️

[1] The protocol MUST NOT define any features that preclude hardware independence 🦋 no locking anyone into one specific machine.

7. Service Attributes 💎

okay so beyond the functional and interface stuff, there are service elements you really need to nail as a protocol designer 💅 This section covers reliability, availability, scalability, maintainability, extensibility, and security.

7.1 Reliability 🛡️

[1] Reliability is a measure of how consistent and dependable a protocol's level of service is 💪 It's a big deal for a domain name management protocol. An unreliable protocol raises the risk of data exchange errors 😬 which at one extreme can directly hurt usability, and at the other extreme can cause a split between the registry's and the registrar's data stores 💀 The protocol MUST include features that maximize reliability at the application protocol layer. Services provided by underlying transport, session, and presentation protocols SHOULD also be considered when addressing application protocol reliability 🧩

[2] The protocol MUST be run over the most reliable transport option available in a given environment 🚀 The protocol MUST NOT implement a service that is otherwise available in an applicable standard transport 🙅‍♀️

[3] Default protocol actions for when a request or event times out MUST be well defined ⏱️ no mystery timeouts, ever.

7.2 Availability 🟢

[1] Availability is a measure of how accessible a protocol's services are for their intended use ✨ For an application layer protocol, availability depends mostly on the software and hardware systems that implement it.

The protocol MUST NOT include any features that impinge on the underlying availability of the software and hardware systems needed to service the protocol 🙈 don't break the thing that's keeping everything alive.

7.3 Scalability 📈

[1] Scalability is a measure of how well a protocol can handle growth while keeping acceptable operational characteristics 🌱 The protocol MUST be capable of operating at an acceptable level as the load on registry and registrar systems increases 💪 it has to keep up as things get busier.

7.4 Maintainability 🛠️

[1] Maintainability is a measure of how easily a protocol can be adapted or modified to handle unforeseen operational needs or defects 🔧 The protocol SHOULD be developed under the nominal working group processes of the IETF, so there's a well-known mechanism for ongoing maintenance 🗂️

7.5 Extensibility 🧚

[1] Extensibility is a measure of how well a protocol can be adapted for future uses that weren't obvious when it was first designed 🔮 The protocol SHOULD provide features that, at a minimum, allow the management of new object types without requiring revisions to the protocol itself 🙌

[2] The requirements in this document are NOT intended to limit the set of objects that might be managed by the protocol 🌈 The protocol MUST include features that allow extension to object types that are not described in this document 🎁

[3] The protocol MUST provide an optional field within all commands whose format and use will be controlled by individual registry policy 🧁 each registry gets to decide how that field gets used.

7.6 Security 🔐

[1] Transactional privacy and integrity services MUST be available at some protocol layer 🫡 no skipping this one.

[2] This document describes requirements for basic user identification and authentication services 🪪 A generic protocol MAY include additional security services to protect against the attacks described here 🛡️ A generic protocol MUST depend on other-layered protocols to provide security services that are not provided in the generic protocol itself 🧅 and a generic protocol that relies on security services from other-layered protocols MUST specify the protocol layers needed to provide them 📋 be clear about who does what, bestie.

8. Other Requirements 🗂️

okay so when you design a generic registry-registrar protocol, you have to think about what's going on in the real operational world 🌎 Areas of concern include database operations, operations, site adaptation, and data collection.

8.1 Database Requirements 🗄️

[1] The protocol MUST NOT have any database dependencies 🙅‍♀️ However, efficient use of database operations and resources still has to be considered as part of the protocol design effort ⚙️ The protocol SHOULD provide atomic features that can be efficiently implemented to minimize database load 💾 small, clean, and easy on the database, we love to see it.

8.2 Operational Requirements ⏰

[1] Registry-registrar interactions at the protocol level SHOULD operate without human intervention 🤖 However, intermediate services that preserve the integrity of the protocol MAY be provided 🧑‍💻 For example, an intermediate service that determines whether a registrant is authorized to register a name in a name space can be provided 🪄

[2] The protocol MUST provide services that allow clients and servers to maintain a consistent understanding of the current date and time 🕰️ so they can effectively manage objects with temporal properties 📅 everybody has to be on the same clock, no cap.

8.3 Site Adaptation Requirements ✨

[1] okay so registries and registrars have totally different business and operational vibes 💅 Governance standards, local laws, customs, and business practices all get a say in how they actually run. So the protocol MUST be flexible enough to operate in diverse registry-registrar environments 🦋

8.4 Data Collection Requirements 🌸

[1] bestie, some of the data swapped between a registrar and a registry can be personal, private, or just sensitive 🙈 Laws and/or business practices might restrict who gets to see it. The protocol MUST provide services to identify data collection policies 🫶

[2] some of the social information exchanged between a registrar and registry might be required to create, manage, or operate Internet or DNS infrastructure facilities, like zone files 🧚 That kind of information is subject to public disclosure per relevant IETF standards.

9. Internationalization Requirements 🌍

[1] [RFC1035] describes Internet host and domain names using characters traditionally found in a subset of the 7-bit US-ASCII character set. Then newer standards like [RFC2130] and [RFC2277] got real about needing protocols for an international Internet 🌈 These and other standards MUST be considered during the protocol design process so a generic registry registrar protocol is usable worldwide ✨

[2] The protocol MUST allow exchange of data in formats consistent with current international agreements for the representation of such objects. In particular, this means addresses MUST include country, telephone numbers MUST start with the international prefix +, and appropriate thought be given to the usability of information in both local and international contexts 🍓 This means some elements (like names and addresses) might need to be represented multiple times, or formatted for different contexts (for instance English/French in Canada, or Latin/ideographic in Japan). It's giving "adapt to every audience" 👑

[3] All date and time values specified in a generic registry-registrar protocol MUST be expressed in Universal Coordinated Time ⏰ Dates and times MUST include information to represent a four-digit calendar year, a calendar month, a calendar day, hours, minutes, seconds, fractional seconds, and the time zone for Universal Coordinated Time. Calendars apart from the Gregorian calendar MUST NOT be used. No cap, that's a hard no 💀

10. IANA Considerations 🎀

This document does not require any action on the part of IANA. Protocol specifications that require IANA action MUST follow the guidelines described in [RFC2434] 💖

11. Security Considerations 🔐

Security is the part you cannot skip, bestie 😭

Security services, including confidentiality, authentication, access control, integrity, and non-repudiation SHOULD be applied to protect interactions between registries and registrars as appropriate. Confidentiality services protect sensitive exchanged information from inadvertent disclosure. Authentication services confirm the claimed identity of registries and registrars before engaging in online transactions. Access control services control access to data and services based on identity. Integrity services guarantee that exchanged data has not been altered between the registry and the registrar. Non-repudiation services provide assurance that the sender of a transaction can not deny being the source of the transaction, and that the recipient cannot deny being the receiver of the transaction 🔥

12. Acknowledgements 🫶

This document was originally written as an individual submission Internet-Draft. The provreg working group later adopted it as a working group document and provided many invaluable comments and suggested improvements. The author wishes to acknowledge the efforts of WG chairs Edward Lewis and Jaap Akkerhuis for their process and editorial contributions 👏

Specific comments that helped guide development of this document were provided by Harald Tveit Alvestrand, Christopher Ambler, Karl Auerbach, Jorg Bauer, George Belotsky, Eric Brunner-Williams, Jordyn Buchanan, Randy Bush, Bruce Campbell, Dan Cohen, Andre Cormier, Kent Crispin, Dave Crocker, Ayesha Damaraju, Lucio De Re, Mats Dufberg, Peter Eisenhauer, Sheer El-Showk, Urs Eppenberger, Patrik Faltstrom, Paul George, Patrick Greenwell, Jarle Greipsland, Olivier Guillard, Alf Hansen, Paul Hoffman, Paul Kane, Shane Kerr, Elmar Knipp, Mike Lampson, Matt Larson, Ping Lu, Klaus Malorny, Bill Manning, Michael Mealling, Patrick Mevzek, Peter Mott, Catherine Murphy, Martin Oldfield, Geva Patz, Elisabeth Porteneuve, Ross Wm. Rader, Budi Rahardjo, Annie Renard, Scott Rose, Takeshi Saigoh, Marcos Sanz, Marcel Schneider, J. William Semich, James Seng, Richard Shockey, Brian Spolarich, William Tan, Stig Venaas, Herbert Vitzthum, and Rick Wesson 🌟

13. References 📚

Normative References:

  • [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

Informative References:

  • [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
  • [RFC2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, R., Cripsin, M. and P. Svanberg, "The Report of the IAB Character Set Workshop", RFC 2130, April 1997.
  • [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.

14. Editor's Address 💌

Scott Hollenbeck
VeriSign Global Registry Services
21345 Ridgetop Circle
Dulles, VA 20166-6503
USA

EMail: shollenbeck@verisign.com

Copyright (C) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement ✨

Funding for the RFC Editor function is currently provided by the Internet Society 🌸

📦 where this page comes from