Re: [eppext] revised draft charter - v2

Peter Koch <pk@DENIC.DE> Mon, 14 September 2015 17:16 UTC

Return-Path: <peter@denic.de>
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 4BAEF1B3C11 for <eppext@ietfa.amsl.com>; Mon, 14 Sep 2015 10:16:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.14
X-Spam-Level: *
X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 Nd81T8S_c0yl for <eppext@ietfa.amsl.com>; Mon, 14 Sep 2015 10:16:33 -0700 (PDT)
Received: from office.denic.de (office.denic.de [IPv6:2a02:568:102:211::1:7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FFAA1B3A3C for <eppext@ietf.org>; Mon, 14 Sep 2015 10:16:33 -0700 (PDT)
Received: from office.denic.de (mailout-6.osl.denic.de [10.122.34.32]) by office.denic.de (Postfix) with ESMTP id 5A3811FB13 for <eppext@ietf.org>; Mon, 14 Sep 2015 19:16:28 +0200 (CEST)
Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) id 1ZbXMh-0000Wh-J8; Mon, 14 Sep 2015 19:16:27 +0200
Received: from localhost by x27.adm.denic.de with local id 1ZbXMh-0001Ga-9R; Mon, 14 Sep 2015 19:16:27 +0200
Date: Mon, 14 Sep 2015 19:16:27 +0200
From: Peter Koch <pk@DENIC.DE>
To: eppext@ietf.org
Message-ID: <20150914171627.GP2480@x28.adm.denic.de>
References: <55E0D247.2020408@elistx.com> <C80127C588F8F2409E2B535AF968B768BA233E3B@kambx1.SIDN.local> <5BFD186DCB661E4D951017B0818285AEDE761E65@kambx1.SIDN.local> <D209C95E.E92F%edward.lewis@icann.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <D209C95E.E92F%edward.lewis@icann.org>
User-Agent: Mutt/1.4.2.3i
Sender: Peter Koch <peter@denic.de>
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/yEZzh2Ln6hJVnXCwpfmjzW2YnTE>
Subject: Re: [eppext] revised draft charter - v2
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: Mon, 14 Sep 2015 17:16:35 -0000

On Mon, Aug 31, 2015 at 01:16:34PM +0000, Edward Lewis wrote:

> I think having a registry-industry focused extensions WG is a good idea.

[...]

> Two questions that come to mind are: Would creating a
> registry-as-a-specific-function WG be something new to the IETF?  (I.e.,
> precedent-setting?)  And would this be better placed in O&M?

The operations part of the protocols might benefit from an assembly
point that combines protocol development and ops background from
both rtegistries, registrars, and vendors.  Whether a shift O{&M}
makes any difference - I do not know, especially given recent developments
w.r.t. out-of-area ADs.

> I'll add - I don't see registries continually evolving over time, past a
> point of maturity.  So a WG would have a limited lifetime, not an
> on-going, ever-expanding function.

We've thought that about the DNS a couple of times. Now look.

That said, the part that makes me nervous is the very prominent position
of ICANN within the charter text.  I understand that that is a motivating
factor, but I'd really wish the IETF was a bit more careful to not become
the 'standards delivery wing' of said organization.  The existence of a
domain name world outside ICANN should be explicitly acknowledged.

The second issue is related to scope.  The past has shown failed attempts
to fire up IETF WGs for developing something constrained by a single
stakeholder and their timeline. I consider this a feature rather than a bug.

In summary, I do not see a real benefit in joining the two groups
into one. If it's meeting logistics, that can be dealt with differently.
The protocols are significantly distinct that two lists shouldn't
really hurt. A 'melting pot' of all things registry protocol stuff is
what should not happen.

-Peter