WG Review: RESTful Provisioning Protocol (rpp)

The IESG <iesg-secretary@ietf.org> Thu, 06 February 2025 20:43 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from mail2.ietf.org (mail2.ietf.org [166.84.6.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 0E72CC1524DC; Thu, 6 Feb 2025 12:43:22 -0800 (PST)
Received: from mail.ietf.org (mail.ietf.org [50.223.129.194]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPSA id 658912662D; Thu, 06 Feb 2025 20:43:21 +0000 (UTC)
Received: from [10.244.8.212] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id 9526EC234FD5; Thu, 6 Feb 2025 12:43:20 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: WG Review: RESTful Provisioning Protocol (rpp)
X-Test-IDTracker: no
X-IETF-IDTracker: 12.35.0
Auto-Submitted: auto-generated
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <173887460026.340.8134788226733788473@dt-datatracker-75c44cbbdf-pxnd6>
Date: Thu, 06 Feb 2025 12:43:20 -0800
Message-ID-Hash: HKYBATECCBYEB5ESTVZBUAN7VDCG7D2J
X-Message-ID-Hash: HKYBATECCBYEB5ESTVZBUAN7VDCG7D2J
X-MailFrom: iesg-secretary@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ietf-announce.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: rpp@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: iesg@ietf.org
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-announce/H1O_rUnboBuBc8-bRJaYTCUW53M>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-announce>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Owner: <mailto:ietf-announce-owner@ietf.org>
List-Post: <mailto:ietf-announce@ietf.org>
List-Subscribe: <mailto:ietf-announce-join@ietf.org>
List-Unsubscribe: <mailto:ietf-announce-leave@ietf.org>

A new IETF WG has been proposed in the Applications and Real-Time Area. The
IESG has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send your
comments to the IESG mailing list (iesg@ietf.org) by 2025-02-16.

RESTful Provisioning Protocol (rpp)
-----------------------------------------------------------------------
Current status: BOF WG

Chairs:
  Andy Newton <andy@hxr.us>
  Darrel Miller <darrel@tavis.ca>

Assigned Area Director:
  Orie Steele <orie@or13.io>

Applications and Real-Time Area Directors:
  Murray Kucherawy <superuser@gmail.com>
  Orie Steele <orie@or13.io>

Mailing list:
  Address: rpp@ietf.org
  To subscribe: https://mailman3.ietf.org/mailman3/lists/rpp.ietf.org/
  Archive: https://mailarchive.ietf.org/arch/browse/rpp

Group page: https://datatracker.ietf.org/group/rpp/

Charter: https://datatracker.ietf.org/doc/charter-ietf-rpp/

# Introduction

The Extensible Provisioning Protocol (EPP) was standardized
([STD69](https://datatracker.ietf.org/doc/std69/)) in 2009 to address the
needs of domain name management between domain name registries and
registrars. Though EPP is still serving the domain name industry well, the
progress in available development, integration and operational patterns,
tools and technologies create a desire to have a provisioning protocol using
the REST architectural style and the JSON data-interchange format. Such
design is expected to take advantage of stateless architecture and widely
deployed solutions such as OpenAPI, associated documentation, testing and
code generation tools, and L4-L7 network services such as API gateways,
authorization servers, load balancers, web servers, web application
firewalls, etc. The successful adoption of Registration Data Access Protocol
(RDAP) by Domain Name Registries (DNRs) and Regional Internet Registries
(RIRs) demonstrates the usefulness of JSON and REST based architectures.

Production deployments of REST and JSON based provisioning protocols by
Country Code Top Level Domains (ccTLDs) have been well received, however
variance across implementations is starting to become a concern.

A standardized REST architecture is expected to allow easier integration
between registries and registrars, thus lowering the costs for domain
registration and new market entrants.

# Scope

The RPP working group is focused on designing a new protocol via a series of
specifications known collectively as the RESTful Provisioning Protocol (RPP).

These specifications target at least level 2 of the Richardson Maturity
Model, using HTTPS and JSON.

The RPP WG considers functional equivalents of functionality from EPP for
domain names, hosts and contacts
([RFC5730](https://datatracker.ietf.org/doc/html/rfc5730),
[5731](https://datatracker.ietf.org/doc/html/rfc5731),
[5732](https://datatracker.ietf.org/doc/html/rfc5732), and
[5733](https://datatracker.ietf.org/doc/html/rfc5733)) and mappings for data
objects, operations, commands and responses.

New functionalities, not having any equivalents in EPP or [EPP
extensions](https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml),
may be defined for RPP.

Given that RPP is intended to co-exist alongside EPP, considerations for
replacing EPP or migration scenarios away from EPP are outside the scope of
the RPP WG.

The REGEXT working group is chartered to maintain and standardize extensions
to EPP. Consequently, any extensions or changes to EPP, including those
related to RPP functionality that do not exist in EPP, are explicitly out of
scope for the RPP working group.

RPP resources are secured with appropriately strong authentication, only
encrypted transports are used to properly safeguard authentication material.

Security requirements for RPP are intentionally generic, enabling operators
to choose the specific authentication mechanisms and degree of automation
that is supported.

# Deliverables

The RPP WG will work on the following milestones within the scope of the
charter:

* core architecture, including extension mechanisms (proposed standard)
* specification(s) regarding the provisioning of domain names using RPP
(proposed standard) * mappings between RPP and EPP (proposed standard)

Milestones: