Re: [weirds] combined rechartering text

Nicolás <> Wed, 26 August 2015 16:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6A64F1A8AA6 for <>; Wed, 26 Aug 2015 09:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.3
X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O-Yy2oGmXLlZ for <>; Wed, 26 Aug 2015 09:38:14 -0700 (PDT)
Received: from ( [IPv6:2001:13c7:7001:4000::8]) by (Postfix) with ESMTP id D319A1A88DC for <>; Wed, 26 Aug 2015 09:38:12 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id E293716B40FCA for <>; Wed, 26 Aug 2015 13:38:10 -0300 (UYT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by ( []) (amavisd-new, port 10024) with ESMTP id 7QWnXIEDxI-b for <>; Wed, 26 Aug 2015 13:38:09 -0300 (UYT)
Received: from [IPv6:2001:13c7:7001:7128:249b:8635:1119:1303] (unknown [IPv6:2001:13c7:7001:7128:249b:8635:1119:1303]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id C265816B40FEA for <>; Wed, 26 Aug 2015 13:38:09 -0300 (UYT)
Message-ID: <>
Date: Wed, 26 Aug 2015 13:38:09 -0300
From: =?windows-1252?Q?Nicol=E1s?= <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------070405090307040508080607"
Archived-At: <>
Subject: Re: [weirds] combined rechartering text
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Aug 2015 16:38:17 -0000

Hi, here Nicolas from LACNIC,

I think this is a very good initial approach on rechartering the WG's.

Maybe the list would provide some feedback to complete a more specifical 
possible workaround to define Milestones and purpose for this new WG.

Until this, I have some doubts about the rechartering...

Will it include the practical deployability and interoping of both 
protocols into consideration?

Is it the idea to Continue with the remaining work from EPP-ext?, or 
maybe, is a good time to extend the scope of EPP-ext to the new EPP 
extensions? including deep watches and comparisons between RDAP protocol 
implicancies or is it just with Informational/BCP purposes?

Nicolas Fiumarelli - LACNIC

El 28/07/15 a las 17:41, Andrew Newton escibió:
> Here is some proposed text for a rechartering focused on both EPP and RDAP.
> It is based on the text James Galvin sent on July 23. However, there
> are two things to note:
> 1. It broadens the allowable set of work items to also include
> informational and BCP documents seeking IETF consensus.
> 2. States that EPP will be the initial focus of work items since it
> has the greater backlog.
> -andy
> --------------
> Draft Proposed Charter EPP/RDAP Extensions Working Group
> The Extensible Provisioning Protocol (EPP, Standard 69) is the
> standard domain name provisioning protocol for top-level domain name
> registries, and the Registration Data Access Protocol (RDAP) is a
> public-facing data access protocol used by domain name and Internet
> number registries. As adoption of these protocols progresses by new
> registries and registrars, it is important to coordinate and
> standardize extensions when necessary.
> 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.
> RDAP, completed by the WEIRDS working group, has a similar extensions
> mechanism and accompanying IANA registries, also governed by expert
> review and requiring published specifications.
> For both protocols, extensions 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
> extensions listed for which it would makes sense to merge them into a
> single standard extension everybody agrees on.
> This working group will be the home of the coordination effort for
> standards track extensions and informational or best practices
> documents needing IETF consensus.  The selection for work items shall
> incorporate the following guidelines.
> 1. Proprietary documented extensions and individual submissions of
> informational or experimental extensions will follow the expert review
> process as specified for EPP and RDAP. These documents will not be
> part of this working groups work or milestones. The working group may
> discuss or advise on these documents.
> 2. Extensions that seek standards track status and other documents in
> need of IETF consensus  can be suggested for WG adoption, and, once
> accepted, proceed to IETF consensus and RFC publication according to
> IETF practices.
> 3. This working group will exist as long as there are relevant
> document work items.  When there are no more document work items, this
> 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.
> 4. Initial work and milestones for this working group will emphasize
> standardization of EPP extensions over RDAP extensions, as EPP has a
> larger backlog of documents seeking adoption at the time of chartering
> for this working group.
> TBD depending on the initial documents selected for standards track.
> _______________________________________________
> weirds mailing list