Re: [eppext] WG Action: Formed Registration Protocols Extensions (regext)

Barry Leiba <> Fri, 04 March 2016 15:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 122BA1A21BC; Fri, 4 Mar 2016 07:33:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9Luh4OOhC12u; Fri, 4 Mar 2016 07:33:52 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4C8931A21B1; Fri, 4 Mar 2016 07:33:49 -0800 (PST)
Received: by with SMTP id i18so21075538igh.1; Fri, 04 Mar 2016 07:33:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=43DaGjmqClyYeEmd4YBkC9hg78+AnwvlRwy8lOhn5yw=; b=oaMqFyjduEFVKCd+VPpfsn5e8Ekbh4jqwSllZCeQ3spHILxGZA9xXxEbWEDcXkIaAO nM1qa/0sOSIejKVBnHNHV+V8oAQJUYUTx47ON+yabilNFZpPGMaI82K7ruB2v9CR5NTl GmsCTrkG3XHbsLrBeQ73V481uZmlBugEAjF9k+rSDBpTvY9O4/pzloJwdEI7bepfEJkw OEkSd3vIzkWCQ6y4WIzjVCBOuX7F+YsCYMYo3ZEzYFMgPpEkNd9y3ExrM5VXffcb9Gi3 hCnGZrCKQ0NRcPAsgdr8V2a7S7HNRjZCtFKtGyaoB4CYbxOuMPd+2QhKBFa6OaTJ6b+u 2vnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=43DaGjmqClyYeEmd4YBkC9hg78+AnwvlRwy8lOhn5yw=; b=fnaWGHSrglLdGYfDTZszZzZX4HbLiFHyR97ETQSzAVFR/2s7spMZChmohfvkHeudOq C0SGhFSuH/zdLS/iOCdiZ9IPcF8jY0HQ4LoT3GugGURMvk4sOLpBtF+QLX2time/l7Dk 59BSgKR9jNQE/DCsf2C8FMj6TQQWehIiUfDZybtVsmSrmf2wvxQWmEkt5GHYQymkSLyR LZKNav7N+CjIDQBFyNbG2YztZhC2n2xmBT9I3cEyPpCFZFiMDrzw/6LwXHEO0L+Mw7rC rTvJuNQJK47Q6zOXQI52ecGVtFHS1ywqmORoFLr633/lup1i2Tt2N6sOomOUJY0uufLd 2J7Q==
X-Gm-Message-State: AD7BkJJcpC1x+3lst8hlr/kntCe/hgzf2a0BWpVoE3ltTsYg2y3e4ITpzCdELU4ZCfnVg0m5fB8bd3EL5qSN/A==
MIME-Version: 1.0
X-Received: by with SMTP id k16mr4061894igf.81.1457105628488; Fri, 04 Mar 2016 07:33:48 -0800 (PST)
Received: by with HTTP; Fri, 4 Mar 2016 07:33:48 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Fri, 4 Mar 2016 10:33:48 -0500
X-Google-Sender-Auth: m3AtLu-XQ6EwqI-nZn7djrktV78
Message-ID: <>
From: Barry Leiba <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: eppext <>, " Group" <>
Subject: Re: [eppext] WG Action: Formed Registration Protocols Extensions (regext)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Mar 2016 15:33:54 -0000

The regext working group charter has been approved, and that replaces
eppext and takes the RDAP follow-on work from weirds.  All eppext and
weirds subscribers were added to the regext list a while ago, and now,
with the regext charter approved, I'll be asking the IT folks to start
forwarding messages that are sent to the eppext and weirds mailing
lists over to the regext mailing list, and we'll formally close the
eppext working group.

Everyone, please use <> in future.

Barry, ART Director

On Fri, Mar 4, 2016 at 9:57 AM, The IESG <> wrote:
> A new IETF WG has been formed in the Applications and Real-Time Area. For
> additional information, please contact the Area Directors or the WG
> Chairs.
> Registration Protocols Extensions (regext)
> -----------------------------------------------------------------------
> Current status: Proposed WG
> Chairs:
>   Jim Galvin <>
>   Antoin Verschuren <>
> Assigned Area Director:
>   Barry Leiba <>
> Applications and Real-Time Area Directors:
>   Barry Leiba <>
>   Ben Campbell <>
>   Alissa Cooper <>
> Mailing list:
>   Address:
>   To subscribe:
>   Archive:
> Charter:
> The Extensible Provisioning Protocol (EPP, Standard 69) is the
> standard domain name provisioning protocol for top-level domain name
> registries.  To avoid many separate EPP extensions that provide
> the same functions, it's important to coordinate and standardize EPP
> extensions.
> The EPP Extensions (EPPEXT) working group completed its first goal of
> creating an IANA registry of EPP extensions.  The registration process
> of the registry is documented in RFC7451.  Extensions may be
> registered for informational purposes as long as there is a published
> specification that has been reviewed by a designated expert.
> The Registration Data Access Protocol (RDAP, RFCs 7480-7484) is the
> proposed standard for retrieving registration metadata from both
> domain name and Regional Internet Registries.  To ensure interoperable
> implementations it's important to coordinate and standardize
> extensions and profiles to be used by registries.
> Extensions in both cases that are targeted for the Standards Track are
> subject to more thorough review and open discussion within the IETF.
> In addition, commonality may be discovered in related extensions,
> especially EPP extensions listed on the EPP extension registry, for
> which it would makes sense to merge them into a single standard
> extension everybody agrees on.
> The REGEXT working group is the home of the coordination effort for
> standards track extensions.  The selection of extensions for standards
> track shall incorporate the following guidelines.
> 1. Proprietary documented extensions and individual submissions of
> informational or experimental EPP extensions will follow the expert
> review process as described in RFC7451 for inclusion in the EPP
> extensions registry. These documents will not be part of the REGEXT
> working group work or milestones. The working group may discuss or
> advise on these documents.
> 2. Extensions that seek standards track status can be suggested for WG
> adoption.  If accepted by the working group then the development of
> the standard may proceed.
> 3. When there are no more proposals for Standards-Track extensions,
> the working group will either close or become dormant, with the
> decision made in consultation with the responsible AD.  The charter
> will be reviewed by the end of 2017 and will be refreshed by
> rechartering if there is still a reason to keep the working group
> going.  In any case, the mailing list will remain open and available
> for the use of the expert review process as described in RFC7451.
> The working group will also identify the requirements for a
> registration protocol that allows a third-party service provider to
> exchange information with a registry without the need of a registrar
> proxy in the middle of the exchange.  These requirements will be
> documented in an Informational RFC.
> The working group will focus initially on the backlog of EPP and RDAP
> extensions.
> Milestones:
>   Mar 2016 - Submit for publication "Launch Phase Mapping for EPP"
>   Mar 2016 - Submit for publication "TMCH functional specifications"
>   Apr 2016 - Submit for publication "EPP and RDAP Status Mapping"
>   Apr 2016 - Submit for publication "Registry Fee Extension for EPP"
>   Apr 2016 - Submit for publication "Reseller Extension for EPP"
>   Apr 2016 - Submit for publication "EPP Reseller Mapping"
>   Jun 2016 - Submit for publication "Verification Code Extension for EPP"
>   Jun 2016 - Submit for publication "EPP China Name Verification Mapping"
>   Jun 2016 - Submit for publication "EPP Domain Name Mapping Extension
> for Bundling Registration"
>   Oct 2016 - Submit for publication "Change Poll Extension for EPP"
>   Oct 2016 - Submit for publication "Allocation Token Extension for EPP"
>   Feb 2017 - Submit for publication draft-ietf-eppext-idnmap
>   Feb 2017 - Submit for publication "EPP IDN Table Mapping"
>   Feb 2017 - Submit for publication "CIRA IDN EPP Extension"
>   Jun 2017 - Submit for publication an informational RFC with
> requirements for a registration protocol for third-party DNS providers