Re: [eppext] final charter description

"Marc Blanchet" <> Thu, 05 November 2015 01:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3DCA31B35A0 for <>; Wed, 4 Nov 2015 17:21:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lMyuC6Qg8eyw for <>; Wed, 4 Nov 2015 17:21:35 -0800 (PST)
Received: from ( [IPv6:2620:0:230:8000::2]) by (Postfix) with ESMTP id 0838F1B35A1 for <>; Wed, 4 Nov 2015 17:21:35 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id D7D95403A2; Wed, 4 Nov 2015 20:21:33 -0500 (EST)
From: "Marc Blanchet" <>
To: "James Galvin" <>
Date: Thu, 05 Nov 2015 10:21:31 +0900
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_A36F7DF2-9DD3-454A-BA2E-BBB12AA5F9CD_="
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.2r5141)
Archived-At: <>
Cc: eppext <>
Subject: Re: [eppext] final charter description
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: Thu, 05 Nov 2015 01:21:37 -0000

few comments on the proposed charter:

Proposed Charter
Registration Protocols Extensions (REGEXT) Working Group

The Extensible Provisioning Protocol (EPP, Standard 69) is the
standard domain name provisioning protocol for top-level domain name
registries, and the Internet Corporation for Assigned Names and
Numbers (ICANN) requires all new generic top-level domain registries
to implement EPP.  To avoid many separate EPP extensions that provide
the same functions, it's important to coordinate and standardize EPP

<MB>I would be more happy to not specifically talk about ICANN 
requirements for gTLD, but more in general for any registries, including 
cctlds.  I would just remove « and the Internet Corporation … to 
implement EPP ».

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.  Some registries are
using it now and many more are expected as ICANN moves towards
requiring it of generic top-level domain registries.

<MB>same comment here.  More over, timing data such as « using it 
now » does not survive well over time. Suggested change is to remove 
the last sentence.

  To ensure
interoperable implementations it's important to coordinate and
standardize extensions and profiles to be used by registries.

Extensions in both cases that seek the status of Internet standard 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. The working group will exist as long as there is an extension
seeking standards track status.  When there are no more proposals
for a standards track extension the working group will either close or
go dormant according to IETF rules.  The mailing list will remain open
and available for the use of the expert review process as described in

The working group will focus initially on the backlog of EPP extensions.

<MB>The last paragraphs are really EPP focused. We already know that 
they are some RDAP extensions that need to be standardized. I think the 
text should reflect that.

On 5 Nov 2015, at 10:09, James Galvin wrote:

> Included in this message is the final charter description that has 
> been previously agreed to by this working group.
> What is missing are the milestones.  A follow up message will propose 
> a draft set of milestones for discussion in the working group meeting 
> (and here on the list of course).
> I'm separating these parts so we focus discussion.
> Jim
> _______________________________________________
> EppExt mailing list