Re: 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]

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