[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: EPP Provreg <ietf-provreg@cafax.se>
From: Ulrich Wisser <liste@publisher.de>
Date: Fri, 05 Feb 2010 14:18:09 +0100
In-Reply-To: <C78F6E8F.37340%jgould@verisign.com>
Sender: owner-ietf-provreg@cafax.se
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310

Hi,

>    1. Don’t include any additional elements.  This means that the server
>       would either validate the passed DS inline with the EPP
>       transaction or would publish all DS that is passed.  

This would be my favorite option. Sorry Eduardo!

>    2. Add a new optional element in the secDNS:dsData (DS Interface) and
>       secDNS:keyData (Key Interface) elements of secDNS:infData.  I
>       propose the use of the secDNS:published element.  

At least I can see a use case here, but even if you know when the ds 
record is published there is still so much guessing about cache updates 
that the option doesn't really help.

>    3. Add a new optional secDNS:childKeyPublished element in the
>       secDNS:dsData (DS Interface) and secDNS:keyData (Key Interface)
>       elements of secDNS:create, secDNS:update, and secDNS:infData.
>        This element would be specified by the client to inform the
>       server which DS has a corresponding DNSKEY published in the child
>       zone.  It would be up to the server to decide the validation and
>       publishing scheme based on this flag.  Option #2 might have to go
>       along with this as well in the event that the server will publish
>       a different set of DS based on offline / asynchronous processing.  

In that case I see a major clash with EPP semantics. The 
childKeyPublished flag should be update able. The current extension 
doesn't allow for this. So the ds record in question would have to be 
removed and added again. If the registry doesn't publish ds records of 
unpublished keys it seems that you shouldn't send the ds record to the 
registry in the first place. If the registry does publish ds records of 
unpublished keys the flag has no function. If the registry checks if the 
key is published before putting it in the zone file, the flag has no 
function either.


Given my above assessment I would prefer to not put in such a flag.

/Ulrich





-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se


Home | Date list | Subject list