Re: [eppext] final charter description

Patrick Mevzek <pm@dotandco.com> Thu, 05 November 2015 02:05 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 0DBA21B363D for <eppext@ietfa.amsl.com>; Wed, 4 Nov 2015 18:05:38 -0800 (PST)
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 BxafxdBxaN2a for <eppext@ietfa.amsl.com>; Wed, 4 Nov 2015 18:05:36 -0800 (PST)
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 366E71B3510 for <eppext@ietf.org>; Wed, 4 Nov 2015 18:05:34 -0800 (PST)
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 tA525PCU007186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Nov 2015 03:05:25 +0100
Received: (from patrick@localhost) by shaktot.patoche.org (8.14.3/8.14.3/Submit) id tA525OWJ007185; Thu, 5 Nov 2015 03:05:24 +0100
Date: Thu, 05 Nov 2015 03:05:23 +0100
From: Patrick Mevzek <pm@dotandco.com>
To: James Galvin <galvin@elistx.com>
Message-ID: <20151105020523.GA12103@home.patoche.org>
References: <563AAC4F.6050907@elistx.com> <A4E1F844-9D5E-43CD-B886-F5CB94809768@viagenie.ca> <1E948341-BA56-498F-8AF9-6382856B8265@viagenie.ca> <563AB498.7050203@elistx.com> <C160E43F-F77B-4DAF-9041-E1E0914D8128@viagenie.ca> <563AB732.9050301@elistx.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <563AB732.9050301@elistx.com>
X-PGP-KeyID: A241FB6B
X-PGP-Fingerprint: 9DA9 5054 7A5D 03FC A9AD 9AFF 1371 9F06 A241 FB6B
X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B
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/ieoWvVmTD9czY08XESJGtflt83s>
Cc: eppext <eppext@ietf.org>
Subject: Re: [eppext] final charter description
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: Thu, 05 Nov 2015 02:05:38 -0000

James Galvin <galvin@elistx.com> 2015-11-05 02:56
> >well, let me rephrase my point, and not concentrating on that specific
> >draft. Is the charter strictly scoped to EPP and RDAP protocols (which
> >seem to be), or is the scope about registration protocols (in which a
> >bit larger scope would enable these initiatives to be in scope). Yes,
> >there is danger for too large scope. But I wanted to at least raise the
> >awareness of the group before we restrict ourselves to RDAP and EPP.
> 
> Thanks for this.
> 
> What do others think?
 
I agree with you that process-wise we should stick to the more or less
currently agreed charter focused purely on EPP/RDAP extensions
(even if I'm in the minority section of people not seeing the benefit
of the merge, but not opposing it)

However, what Jacques's draft proposes comes from a real problem that
is spoken about in various fora (in dnsop a little ago, various blog
posts from Cloudflare, etc…), but it does not seem there is a specific
working group or such where it should be discussed and worked on.

The closest WG to discuss that would still seems to be REGEXT for me,
especially because, for example, James Gould verification EPP
extension could be also a tool to achieve the goal described above.

So in short, even if the charter sticks to EPP/RDAP extensions, there
should be discussion somewhere, and I would say preferably here in the
absence of better choice, on
the problems that this specific draft tackles.

-- 
Patrick Mevzek