Re: [DNSOP] CPE devices doing DNSSEC

Patrik Wallstrom <pawal@blipp.com> Sun, 09 March 2014 10:19 UTC

Return-Path: <pawal@blipp.com>
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 C7F151A0334 for <dnsop@ietfa.amsl.com>; Sun, 9 Mar 2014 03:19:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.547
X-Spam-Level:
X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] 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 8mePffN83lL9 for <dnsop@ietfa.amsl.com>; Sun, 9 Mar 2014 03:19:20 -0700 (PDT)
Received: from vic20.blipp.com (vic20.blipp.com [192.195.142.21]) by ietfa.amsl.com (Postfix) with ESMTP id C51BF1A0240 for <dnsop@ietf.org>; Sun, 9 Mar 2014 03:19:19 -0700 (PDT)
Received: from [192.168.0.118] (h185n2-asp-a13.ias.bredband.telia.com [217.210.64.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by vic20.blipp.com (Postfix) with ESMTPSA id 09A4D38200; Sun, 9 Mar 2014 11:19:13 +0100 (CET)
Content-Type: multipart/signed; boundary="Apple-Mail=_7B6A52BB-3AFC-484D-AEB1-54E7D91D0C2D"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Patrik Wallstrom <pawal@blipp.com>
In-Reply-To: <531C2637.6020405@frobbit.se>
Date: Sun, 09 Mar 2014 11:19:07 +0100
Message-Id: <6175B0CC-D8E3-44BB-83DD-7DA8548E6120@blipp.com>
References: <20140307100524.2F42810CD58F@rock.dv.isc.org> <A0D47DA8-6E19-4A61-8A7C-FE960A0FA7E9@cybersecurity.org> <20140308090009.5E51210D1595@rock.dv.isc.org> <531C2637.6020405@frobbit.se>
To: Patrik Fältström <paf@frobbit.se>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/wlyRQfif7voMWw2ayAKd00EuFrQ
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 10:19:22 -0000

On 09 Mar 2014, at 09:28, Patrik Fältström <paf@frobbit.se> wrote:

> 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. And do not have so much interest at all to do more
> than many an API that is specific for them that faces the registrant.
> 
> We have been through this hundreds of times before and I think the
> blaming _registrars_ as the ones that have an incompatible portion of
> the system must stop.

But the fact is that EPP is several magnitudes better harmonized between TLDs compared to that registrars are offering their customers. There is no way around that today, and the registrars have no incentive at all to improve the situation. For all the registrars to offer the same API to their customers would really remove the lock-in effect that the proprietary interfaces that they have today.

So how could we change this? I don’t see this happening from a standard organization at all. So yes - registrars is really a big reason for incompatibility. Registries could easily bypass the current rrr model by exposing API:s directly to registrants, but it wouldn’t be very popular with the registrars…