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 Fältström <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
- [DNSOP] CPE devices doing DNSSEC Mark Andrews
- Re: [DNSOP] CPE devices doing DNSSEC Joe Abley
- Re: [DNSOP] pushing updates to the parent Tony Finch
- Re: [DNSOP] pushing updates to the parent Joe Abley
- Re: [DNSOP] CPE devices doing DNSSEC Paul Hoffman
- Re: [DNSOP] pushing updates to the parent Mark Andrews
- Re: [DNSOP] CPE devices doing DNSSEC Mark Andrews
- Re: [DNSOP] pushing updates to the parent Paul Wouters
- Re: [DNSOP] CPE devices doing DNSSEC Jim Reid
- Re: [DNSOP] CPE devices doing DNSSEC Patrik Fältström
- Re: [DNSOP] CPE devices doing DNSSEC Patrik Fältström
- Re: [DNSOP] CPE devices doing DNSSEC Patrik Wallstrom
- Re: [DNSOP] CPE devices doing DNSSEC Patrik Fältström
- Re: [DNSOP] CPE devices doing DNSSEC Patrik Wallstrom
- Re: [DNSOP] CPE devices doing DNSSEC Patrik Fältström
- Re: [DNSOP] CPE devices doing DNSSEC Patrik Fältström
- Re: [DNSOP] CPE devices doing DNSSEC Patrick Mevzek
- Re: [DNSOP] CPE devices doing DNSSEC Patrick Mevzek
- Re: [DNSOP] pushing updates to the parent Mark Andrews
- Re: [DNSOP] pushing updates to the parent Paul Wouters