Re: [provreg] Example of stupid inconsistencies between registries

[MICHAEL YOUNG <[e-mail]>]

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
> [e-mail]
>  
> 703-948-3271 (Office)
> 12061 Bluemont Way
> Reston, VA 20190
> VerisignInc.com
> 
> 
> 
> From: MICHAEL YOUNG <[e-mail]>
> Date: Mon, 5 Mar 2012 08:38:50 -0500
> To: James Gould <[e-mail]>
> Cc: Patrik Fältström <[e-mail]>, "Michele Neylon :: Blacknight" <[e-mail]>, "<[e-mail]>" <[e-mail]>
> 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
>> [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
>> 
>> _______________________________________________
>> provreg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/provreg
> 
> 
> 
> 
> MICHAEL YOUNG
> [e-mail]
> 
> 
> 
> 




MICHAEL YOUNG
[e-mail]