Re: [eppext] final charter description

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5D31D1B3600 for <>; Wed, 4 Nov 2015 17:28:49 -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 PfLuv9RNikzZ for <>; Wed, 4 Nov 2015 17:28:47 -0800 (PST)
Received: from ( [IPv6:2620:0:230:8000::2]) by (Postfix) with ESMTP id 8A6FB1B35FE for <>; Wed, 4 Nov 2015 17:28:46 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 64CE5403A2; Wed, 4 Nov 2015 20:28:45 -0500 (EST)
From: "Marc Blanchet" <>
To: "James Galvin" <>
Date: Thu, 05 Nov 2015 10:28:43 +0900
Message-ID: <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_01109772-5216-4903-91C2-2D81973BBD8B_="
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:28:49 -0000

have another comment about charter: should topics like this 
(draft-latour-dnsoperator-to-rrr-protocol-00) be in scope of the new wg? 
if yes, then we may want to make it so.


On 5 Nov 2015, at 10:21, Marc Blanchet wrote:

> 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
> extensions.
> <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 ».
> </MB>
> 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.
> </MB>
> 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
> RFC7451.
> 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.
> </MB>
> 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
> _______________________________________________
> EppExt mailing list