Re: [provreg] Example of stupid inconsistencies between registries

["Gould, James" <[e-mail]>]

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
[e-mail]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com







On 3/5/12 6:04 AM, "Patrik Fältström" <[e-mail]> 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
>>> [e-mail]
>>> 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. [phone]
>> US: 213-233-1612
>> Locall: 1850 929 929
>> Direct Dial: [phone]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/provreg
>
>_______________________________________________
>provreg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/provreg