Re: Example of stupid inconsistencies between registries
MICHAEL YOUNG <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
Sorry I was being quip, I didn't literally mean "vote" :-) I agree with you, a mix is not adding true value to the solution. -M On 2012-03-05, at 8:49 AM, Gould, James wrote: > 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 > > <86BF0728-DD04-4F90-8380-5AA8A9AB5D0B[22].png> > > James Gould > Principal Software Engineer > [email protected] > > 703-948-3271 (Office) > 12061 Bluemont Way > Reston, VA 20190 > VerisignInc.com > > > > From: MICHAEL YOUNG <[email protected]> > Date: Mon, 5 Mar 2012 08:38:50 -0500 > To: James Gould <[email protected]> > Cc: Patrik Fältström <[email protected]>, "Michele Neylon :: Blacknight" <[email protected]>, "<[email protected]>" <[email protected]> > 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 >> [email protected] >> >> 703-948-3271 (Office) >> 12061 Bluemont Way >> Reston, VA 20190 >> VerisignInc.com >> >> >> >> >> >> >> >> On 3/5/12 6:04 AM, "Patrik Fältström" <[email protected]> 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 >>>>> [email protected] >>>>> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/provreg >>> >>> _______________________________________________ >>> provreg mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/provreg >> >> _______________________________________________ >> provreg mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/provreg > > > > > MICHAEL YOUNG > [email protected] > > > > MICHAEL YOUNG [email protected] _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg