Re: [eppext] rechartering

Patrick Mevzek <pm@dotandco.com> Wed, 29 July 2015 00:03 UTC

Return-Path: <patrick@shaktot.patoche.org>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682981B347E for <eppext@ietfa.amsl.com>; Tue, 28 Jul 2015 17:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level:
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGDG6_406yrL for <eppext@ietfa.amsl.com>; Tue, 28 Jul 2015 17:03:44 -0700 (PDT)
Received: from shaktot.patoche.org (shaktot.patoche.org [212.85.152.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64EA21A0103 for <eppext@ietf.org>; Tue, 28 Jul 2015 17:03:25 -0700 (PDT)
Received: from shaktot.patoche.org (localhost.localdomain [127.0.0.1]) by shaktot.patoche.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t6T03G2Y006039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Jul 2015 02:03:16 +0200
Received: (from patrick@localhost) by shaktot.patoche.org (8.14.3/8.14.3/Submit) id t6T03GOx006038; Wed, 29 Jul 2015 02:03:16 +0200
Date: Wed, 29 Jul 2015 02:03:15 +0200
From: Patrick Mevzek <pm@dotandco.com>
To: eppext@ietf.org
Message-ID: <20150729000315.GA30829@home.patoche.org>
References: <CAAQiQRdBDKb8NF+d2COxTVCbx7MMtV4dsTRDSqBotq6XroHxBQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAAQiQRdBDKb8NF+d2COxTVCbx7MMtV4dsTRDSqBotq6XroHxBQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: shaktot_dot_patoche_dot_org on 212.85.152.86
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/YMw2a3slB-yMmg89P3fIiOPUyes>
Subject: Re: [eppext] rechartering
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jul 2015 00:03:46 -0000

Andrew Newton <andy@hxr.us> 2015-07-27 20:22
> I'd like to offer another idea for the rechartering of this working group.
> Instead of focusing exclusively on EPP extensions, would it be better if we
> rechartered to focus on protocol issues of Internet registries... more
> specifically EPP and RDAP.

I find the idea interesting but I'm not 100% convinced.

As for EPP & RDAP I believe the timeframes and audiences are not the
same:

- EPP is now an "old" protocol, used by all gTLDs, and many ccTLDs
  registries ; AFAIK it is not used outside of the domain name
business, and seldom used outside of domain name registries; there is
no clear indication of any work, outside of technical areas, to try
improving EPP, for example by reducing the number of extensions,
forcing registries to implement some of them, etc…

- RDAP is new, used by a very small number of domain name registries,
  but also used outside of the domain name business, by RIRs. There is
a clear indication of work outside of IETF to impose a common set of
features/recommandations to all gTLDs registries that will need or may
need in the future to implement it, contractually.

So, having a place to discuss all internet registries protocol issues
is good/mandatory, but this may as well be the regops or the gtld-tech
or another mailing-list, not necessarily an IETF WG merging all
extensions issues.

Also, you could even argue that the lager WG could also be merged
(since it is related to protocol issues of Internet registries too),
and maybe even dane or dnsop…

At the end of the day, I think what could be used as a criteria is:
will this kind of merge in topics foster more work and feedback, and
hence going forward faster, or will it make no change?

-- 
Patrick Mevzek