Re: [provreg] Example of stupid inconsistencies between registries
MICHAEL YOUNG <michael@mwyoung.ca> Mon, 05 March 2012 13:39 UTC
Return-Path: <michael@mwyoung.ca>
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 8EDB021F86FD for <provreg@ietfa.amsl.com>; Mon, 5 Mar 2012 05:39:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Level:
X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1]
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 CiyYfCa6ZiPl for <provreg@ietfa.amsl.com>; Mon, 5 Mar 2012 05:39:07 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF9A21F86B9 for <provreg@ietf.org>; Mon, 5 Mar 2012 05:39:06 -0800 (PST)
Received: by iazz13 with SMTP id z13so6537572iaz.31 for <provreg@ietf.org>; Mon, 05 Mar 2012 05:39:06 -0800 (PST)
Received-SPF: pass (google.com: domain of michael@mwyoung.ca designates 10.43.134.199 as permitted sender) client-ip=10.43.134.199;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of michael@mwyoung.ca designates 10.43.134.199 as permitted sender) smtp.mail=michael@mwyoung.ca
Received: from mr.google.com ([10.43.134.199]) by 10.43.134.199 with SMTP id id7mr13085057icc.21.1330954746681 (num_hops = 1); Mon, 05 Mar 2012 05:39:06 -0800 (PST)
Received: by 10.43.134.199 with SMTP id id7mr10778955icc.21.1330954746514; Mon, 05 Mar 2012 05:39:06 -0800 (PST)
Received: from [10.244.70.34] (static-67-226-172-181.ptr.terago.net. [67.226.172.181]) by mx.google.com with ESMTPS id x1sm11519700igc.16.2012.03.05.05.39.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Mar 2012 05:39:04 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_CD132993-AA2A-497F-9D78-C19366D9D4F3"
From: MICHAEL YOUNG <michael@mwyoung.ca>
In-Reply-To: <CB7A233F.19750%jgould@verisign.com>
Date: Mon, 05 Mar 2012 08:38:50 -0500
Message-Id: <4A48A5DC-683E-4B9E-9485-EB22A1301895@mwyoung.ca>
References: <CB7A233F.19750%jgould@verisign.com>
To: "Gould, James" <JGould@verisign.com>
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQkIVzL8lsYsKQh3CbgjRRD6g7pcavi2C1XZOpdNwjtwGKhoJn57X7ztUK5jubk3R2Bnl85U
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:39:08 -0000
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 > > 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> 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 >>>> 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 >>> https://www.ietf.org/mailman/listinfo/provreg >> >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg MICHAEL YOUNG 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