Re: [DNSOP] CPE devices doing DNSSEC

Patrick Mevzek <Patrick.Mevzek@afnic.fr> Sun, 09 March 2014 13:37 UTC

Return-Path: <Patrick.Mevzek@afnic.fr>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD691A022D for <dnsop@ietfa.amsl.com>; Sun, 9 Mar 2014 06:37:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level:
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] 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 EVXnY5V6ErvU for <dnsop@ietfa.amsl.com>; Sun, 9 Mar 2014 06:37:03 -0700 (PDT)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) by ietfa.amsl.com (Postfix) with ESMTP id 71FE91A011D for <dnsop@ietf.org>; Sun, 9 Mar 2014 06:37:03 -0700 (PDT)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 3F7162804D5; Sun, 9 Mar 2014 14:36:58 +0100 (CET)
Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 39F402804CE; Sun, 9 Mar 2014 14:36:58 +0100 (CET)
Received: from [IPv6:::1] (citrine.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:96]) by relay2.nic.fr (Postfix) with ESMTP id F3888AD3121; Sun, 9 Mar 2014 14:36:27 +0100 (CET)
Message-ID: <1394372187.19434.14.camel@citrine-mobile>
From: Patrick Mevzek <Patrick.Mevzek@afnic.fr>
To: Patrik =?ISO-8859-1?Q?F=E4ltstr=F6m?= <paf@frobbit.se>
Date: Sun, 09 Mar 2014 14:36:27 +0100
In-Reply-To: <531C2637.6020405@frobbit.se>
References: <20140307100524.2F42810CD58F@rock.dv.isc.org> <A0D47DA8-6E19-4A61-8A7C-FE960A0FA7E9@cybersecurity.org> <20140308090009.5E51210D1595@rock.dv.isc.org> <531C2637.6020405@frobbit.se>
Organization: AFNIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.6.4-0ubuntu1
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/vc5-Nua3TAus_sRnYkLwobA8PG0
Cc: dnsop@ietf.org, Paul Hoffman <paul.hoffman@cybersecurity.org>
Subject: Re: [DNSOP] CPE devices doing DNSSEC
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Mar 2014 13:37:04 -0000

Le dimanche 09 mars 2014 à 08:28 +0000, Patrik Fältström a écrit :
> 
> On 2014-03-08 09:00, Mark Andrews wrote:
> > They have failed to invent / document a common standard way for
> > machine updates to work.  They could have quite easily got together
> > anytime in the last decade and done a standardised update protocol.
> > 
> > But they haven't.
> 
> As long as the registries have _NOT_ unified their extensions of
> whatever fluffy things they want, so that I as a registrar _really_ can
> use the same EPP implementation to more than one (backend) registry,
> then registrars have to spend energy and real $$ to implement those
> incompatibilities.

These are not incompatibilities. It is by design, sort of.

While I can agree with you on many aspects of the sad current state of
EPP (having both implemented multiple client/server EPP stuff, and
having done presentations on EPP in various venues), the fact is that
trying to achieve 100% uniformity will never happen.

Registries, and specifically ccTLD registries, have distinct local
rules. They will never be exactly the same. You can find many voices
claiming that the current new batch of gTLDs make them all the same
because ICANN forces so many technical details in contractual terms.
Those voices see that as a downside, reducing differences means reducing
interest and differentiation biases.

It would be great if registries standardized parts that are needed the
same way in more than one of them, for example the case of change of
registrant ("trade").

Speaking for my own choir, having an EPP implementation able to speak
with 60+ TLDs shows that you _can_ have the same piece of code talking
into account the differences, which of course you need to hide in some
level of indirection (standard law of computer science).

There will always be some differences. Trying to squeeze them will not
work. Trying to find redundant extensions and merge them may work but
not without a lot of (non technical) work. Convincing registries to
document their EPP extension and even publish them as ID or RFC would be
great but not a simple task. We will see how EPPEXT goes along.

-- 
Patrick Mevzek