Re: [provreg] Example of stupid inconsistencies between registries
"Gould, James" <JGould@verisign.com> Mon, 05 March 2012 13:50 UTC
Return-Path: <JGould@verisign.com>
X-Original-To: provreg@ietfa.amsl.com
Delivered-To: provreg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47BB21F85EC for <provreg@ietfa.amsl.com>; Mon, 5 Mar 2012 05:50:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.718
X-Spam-Level:
X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsQMj-n5pmcp for <provreg@ietfa.amsl.com>; Mon, 5 Mar 2012 05:50:02 -0800 (PST)
Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 5A22F21F8599 for <provreg@ietf.org>; Mon, 5 Mar 2012 05:49:54 -0800 (PST)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKT1TEeht5u6EN7KnXvDd1GA1kNgo6BAgt@postini.com; Mon, 05 Mar 2012 05:49:56 PST
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q25DnksU000781; Mon, 5 Mar 2012 08:49:46 -0500
Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 08:49:46 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Mon, 5 Mar 2012 08:49:45 -0500
From: "Gould, James" <JGould@verisign.com>
To: MICHAEL YOUNG <michael@mwyoung.ca>
Thread-Topic: [provreg] Example of stupid inconsistencies between registries
Thread-Index: AQHM+r0q7eo1z51rQ0WnxvppIby9dZZb3HqAgAABYgD//9JTgIAAWMAA//+vN4A=
Date: Mon, 05 Mar 2012 13:49:45 +0000
Message-ID: <CB7A2CE2.19783%jgould@verisign.com>
In-Reply-To: <4A48A5DC-683E-4B9E-9485-EB22A1301895@mwyoung.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [10.173.152.4]
Content-Type: multipart/related; boundary="_004_CB7A2CE219783jgouldverisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginalArrivalTime: 05 Mar 2012 13:49:46.0153 (UTC) FILETIME=[D3479190:01CCFAD6]
Cc: Patrik Fältström <patrik@frobbit.se>, "<provreg@ietf.org>" <provreg@ietf.org>
Subject: Re: [provreg] Example of stupid inconsistencies between registries
X-BeenThere: provreg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: EPP discussion list <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>, <mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/provreg>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>, <mailto:provreg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Mar 2012 13:50:04 -0000
Michael, I'm not voting but simply covering how the two interfaces made it into the RFC. I can see the basis for both interfaces, but I certainty don't believe that a mix in a single registry is workable. -- JG [cid:D7B04551-15CB-4284-8A3F-DA2987FAB4B4] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: MICHAEL YOUNG <michael@mwyoung.ca<mailto:michael@mwyoung.ca>> Date: Mon, 5 Mar 2012 08:38:50 -0500 To: James Gould <jgould@verisign.com<mailto:jgould@verisign.com>> Cc: Patrik Fältström <patrik@frobbit.se<mailto:patrik@frobbit.se>>, "Michele Neylon :: Blacknight" <michele@blacknight.ie<mailto:michele@blacknight.ie>>, "<provreg@ietf.org<mailto:provreg@ietf.org>>" <provreg@ietf.org<mailto:provreg@ietf.org>> Subject: Re: [provreg] Example of stupid inconsistencies between registries James, I'm not sure from what you've written here, what your vote is, I think it's for the ds data interface? I'm for the "thin" model and agree it should be a must. BTW, in all fairness, we all miss the opportunity to raise issues on these lists - it's tough to stay on top of the discussion flow when you have a day job as well. -Michael On 2012-03-05, at 8:21 AM, Gould, James wrote: Patrik, This was discussed on this list in late 2009. Ulrich Wisser brought up on the list on October 28, 2009 "that .SE and other registries considered to become a "fat" registry and take in the public keys instead of the ds records". Support for a "thin" DNSSEC registry as a MUST with the option for a "fat" registry was never discussed on the list. I believe that a mix of "thin" and "fat" would make things more complex since the registrars would need to support both instead of one interface for the registries that do support the "fat" model. Think about handling transfers between registrars where the gaining registrar supports only the "thin" model and the losing registrar supports both "thin" and "fat". There was support on this list and no concerns raised in adding support for the key data interface to the draft. You were active on the list while this was being discussed and never expressed any concerns in support for the key data interface. What is in the RFC supports the models of "thin" with the ds data interface and "fat" with the key data interface with an either or option for the registries. The registries that I work on support the "thin" model with the ds data interface. -- JG James Gould Principal Software Engineer jgould@verisign.com<mailto:jgould@verisign.com> 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 3/5/12 6:04 AM, "Patrik Fältström" <patrik@frobbit.se<mailto:patrik@frobbit.se>> wrote: This one is specifically irritating as it requires in worst case massive explanations, education and web/REST interface implementations that are dependent on the TLD. I.e. something a registrar can not "hide" from the registrant. I am not happy about differences that cost registrars hard work of various kinds. But I am definitely not happy of things that cost registrant things. So, for this specific case, I would like to see a MUST in at least the DS interface. Patrik On 5 mar 2012, at 11:59, Michele Neylon :: Blacknight wrote: Patrik Welcome to our world :) We see inconsistencies between registries all the time - it makes integration with new registry providers painful and as a result we tend to focus on the ones whose quirks we've already dealt with Regards Michele On 5 Mar 2012, at 10:43, Patrik Fältström wrote: According to RFC 5910, section 4, there are two alternative interfaces for managing DNSSEC key data when interfacing with a registry. The RFC does not explicitly say whether a registry must implement one or the other. I have successfully implemented in a web interface, an API for registrants etc, the DS interface as the client do believe passing DS data is the easiest. After all that is what is to be signed by the parent. I just encountered a registry that "want to set a limit on what digest algorithms to use" and to do that, they have decided to not implement the DS interface and only support the KEY interface. I can accept limitations on what digest algorithms they accept, but not limitations by not supporting DS. Reactions? Patrik _______________________________________________ provreg mailing list provreg@ietf.org<mailto:provreg@ietf.org> https://www.ietf.org/mailman/listinfo/provreg Mr Michele Neylon Blacknight Solutions ♞ Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.biz http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 _______________________________________________ provreg mailing list provreg@ietf.org<mailto:provreg@ietf.org> https://www.ietf.org/mailman/listinfo/provreg _______________________________________________ provreg mailing list provreg@ietf.org<mailto:provreg@ietf.org> https://www.ietf.org/mailman/listinfo/provreg _______________________________________________ provreg mailing list provreg@ietf.org<mailto:provreg@ietf.org> https://www.ietf.org/mailman/listinfo/provreg MICHAEL YOUNG michael@mwyoung.ca<mailto:michael@mwyoung.ca>
- [provreg] Example of stupid inconsistencies betwe… Patrik Fältström
- Re: [provreg] Example of stupid inconsistencies b… Michele Neylon :: Blacknight
- Re: [provreg] Example of stupid inconsistencies b… Patrik Fältström
- Re: [provreg] Example of stupid inconsistencies b… Anthony Kirby
- Re: [provreg] Example of stupid inconsistencies b… Peter Koch
- Re: [provreg] Example of stupid inconsistencies b… Patrik Fältström
- Re: [provreg] Example of stupid inconsistencies b… Gould, James
- Re: [provreg] Example of stupid inconsistencies b… Patrik Fältström
- Re: [provreg] Example of stupid inconsistencies b… MICHAEL YOUNG
- Re: [provreg] Example of stupid inconsistencies b… Andrew Sullivan
- Re: [provreg] Example of stupid inconsistencies b… Gould, James
- Re: [provreg] Example of stupid inconsistencies b… Patrik Fältström
- Re: [provreg] Example of stupid inconsistencies b… Patrik Fältström
- Re: [provreg] Example of stupid inconsistencies b… Michele Neylon :: Blacknight
- Re: [provreg] Example of stupid inconsistencies b… Peter Koch
- Re: [provreg] Example of stupid inconsistencies b… Patrik Fältström
- Re: [provreg] Example of stupid inconsistencies b… Klaus Malorny
- Re: [provreg] Example of stupid inconsistencies b… Klaus Malorny
- Re: [provreg] Example of stupid inconsistencies b… MICHAEL YOUNG
- Re: [provreg] Example of stupid inconsistencies b… MICHAEL YOUNG
- Re: [provreg] Example of stupid inconsistencies b… Gould, James
- Re: [provreg] Example of stupid inconsistencies b… Andrew Sullivan
- Re: [provreg] Example of stupid inconsistencies b… Andrew Sullivan
- Re: [provreg] Example of stupid inconsistencies b… Howard Eland
- Re: [provreg] Example of stupid inconsistencies b… Benoit Levac
- Re: [provreg] Example of stupid inconsistencies b… Patrik Fältström
- Re: [provreg] Example of stupid inconsistencies b… James Mitchell
- Re: [provreg] Example of stupid inconsistencies b… Jay Daley
- Re: [provreg] Example of stupid inconsistencies b… Patrik Fältström
- Re: [provreg] Example of stupid inconsistencies b… Jay Daley
- Re: [provreg] Example of stupid inconsistencies b… Patrik Fältström
- Re: [provreg] Example of stupid inconsistencies b… Peter Koch
- Re: [provreg] Example of stupid inconsistencies b… Antoin Verschuren
- Re: [provreg] Example of stupid inconsistencies b… Mark Elkins
- Re: [provreg] Example of stupid inconsistencies b… Antoin Verschuren
- Re: [provreg] Example of stupid inconsistencies b… Gould, James
- Re: [provreg] Example of stupid inconsistencies b… Michael Young
- Re: [provreg] Example of stupid inconsistencies b… Andrew Sullivan
- Re: [provreg] Example of stupid inconsistencies b… Michael Young
- [provreg] DNSSEC operator change [Re: Example of … Peter Koch
- Re: [provreg] DNSSEC operator change [Re: Example… Michael Young
- Re: [provreg] Example of stupid inconsistencies b… Frederico A C Neves
- Re: [provreg] Example of stupid inconsistencies b… Patrik Fältström
- Re: [provreg] Example of stupid inconsistencies b… Peter Koch
- Re: [provreg] Example of stupid inconsistencies b… Howard Eland
- Re: [provreg] Example of stupid inconsistencies b… Ulrich Wisser