Re: Example of stupid inconsistencies between registries

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
[email protected]

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com


From: MICHAEL YOUNG <[email protected]<mailto:[email protected]>>
Date: Mon, 5 Mar 2012 08:38:50 -0500
To: James Gould <[email protected]<mailto:[email protected]>>
Cc: Patrik Fältström <[email protected]<mailto:[email protected]>>, "Michele Neylon :: Blacknight" <[email protected]<mailto:[email protected]>>, "<[email protected]<mailto:[email protected]>>" <[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/provreg




MICHAEL YOUNG
[email protected]<mailto:[email protected]>

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg