Re: [DNSOP] CPE devices doing DNSSEC

Patrick Mevzek <Patrick.Mevzek@afnic.fr> Sun, 09 March 2014 13:28 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 5CE871A0339 for <dnsop@ietfa.amsl.com>; Sun, 9 Mar 2014 06:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.349
X-Spam-Level:
X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35] 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 gy-WcXuRddHJ for <dnsop@ietfa.amsl.com>; Sun, 9 Mar 2014 06:28:13 -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 086821A031D for <dnsop@ietf.org>; Sun, 9 Mar 2014 06:28:13 -0700 (PDT)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 5C7652803A8 for <dnsop@ietf.org>; Sun, 9 Mar 2014 14:28:07 +0100 (CET)
Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 588D4280367 for <dnsop@ietf.org>; Sun, 9 Mar 2014 14:28:07 +0100 (CET)
Received: from [IPv6:::1] (citrine.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:96]) by relay1.nic.fr (Postfix) with ESMTP id 2F57F4C0081; Sun, 9 Mar 2014 14:27:37 +0100 (CET)
Message-ID: <1394371657.19434.7.camel@citrine-mobile>
From: Patrick Mevzek <Patrick.Mevzek@afnic.fr>
To: dnsop@ietf.org
Date: Sun, 09 Mar 2014 14:27:37 +0100
In-Reply-To: <20140308090009.5E51210D1595@rock.dv.isc.org>
References: <20140307100524.2F42810CD58F@rock.dv.isc.org> <A0D47DA8-6E19-4A61-8A7C-FE960A0FA7E9@cybersecurity.org> <20140308090009.5E51210D1595@rock.dv.isc.org>
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/uvw_5IIDBm8xrM_sZEY2cV4Th9o
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:28:15 -0000

Le samedi 08 mars 2014 à 20:00 +1100, Mark Andrews a écrit :
> > > 	I know Registrars don't like to be told what to do
> > 
> > +1
> 
> But they get told to do EPP to talk to the registries.
> 
> 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 have no incentive to do it!
No financial incentive anyway.

Registries have incentives to use EPP because it makes registrars' life
easier hence more registrars hence more channels for each registry hence
more domain names sold. Same setup for registrars: more registries using
EPP means less additional work each time they have to integrate one new
registry.

On the contrary, it is rare to have customers using more than one
registrars for all of their domain name assets. Hence, registrants build
specific tools to discuss with their registrars and life is good…  of
course until they need to switch to another provider.

Registries have the same problem on a border case problem (which may be
addressed with the eppext working group): they have no incentive to
standardize their own EPP extensions, and the parts that are needed in
the same way among multiple registries.

So, in short, I suspect we should not criticize nor wait for registrars
to build such standardized protocol because for them currently this
would be only additional work with no benefit what so ever (those
needing it already have some kind of local API).
Put it differently, it will work if some incentives are found, be it
contractual or otherwise.

I'm speaking as a former registrar dev having to handle multiple
registries at the RRP time with EPP not already dry when registries
tried to use it, and as a developer of an abstract API over registrars
API which gets no traction, for the obvious reason outlined above.

-- 
Patrick Mevzek