Re: [ietf-provreg] Revision of 4310

[James Gould <jgould@verisign.com>]

Title: Re: [ietf-provreg] Revision of 4310

Andrew,

I don’t understand why the client wouldn’t just add the DS when it becomes active to the server instead of pre-publishing and activating.  Adding an active attribute adds a new model that could cause confusion for the clients interfacing with different servers and it doesn’t really add anything that can’t be handled today by the client.  Adding another attribute that could change frequently like an active flag could pose an issue of support with the secDNS:add, secDNS:rem, and secDNS:chg, where the only way to change the attribute is to use a secDNS:add and secDNS:rem of the same DS (or key), or use the secDNS:chg to replace all DS (or key) data.  I believe this interface is acceptable for the optional maxSigLife attribute, but would become onerous for a more frequently used attribute like an active flag.  

-- 


JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

 
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or Registry  Sensitive information intended solely for the recipient and, thus may not be  retransmitted, reproduced or disclosed without the prior written consent of  VeriSign Naming and Directory Services.  If you have received  this e-mail message in error, please notify the sender immediately by  telephone or reply e-mail and destroy the original message without making a  copy.  Thank you.

---

From: Andrew Sullivan <ajs@shinkuro.com>
Date: Tue, 26 Jan 2010 09:06:17 -0500
To: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] Revision of 4310

On Tue, Jan 26, 2010 at 06:56:24AM +0100, Patrik Fältström wrote:

> I think it is much better the way it is now, that all DS the
> registry know about are active. To turn the active/not active flag
> on and off epp transactions are needed anyways, so the client can as
> well remove/add the keys instead.
>
> I.e. I do not see any need for the registry to keep track of
> active/not active keys, and need to get much more explanation why
> this is needed to be convinced we should change what we have today.

Actually, I can think of a use for this, or something like it.  If you
wanted to pre-publish keys in the parent, and the parent is checking
for the corresponding key in the child zone, then you can't do that
with the bits available in the protocol now.  But if we had a way to
say, "Put this key in, but it's not active now," that would be a way
to pre-publish the DS without the corresponding DNSKEY in the child
zone, even if the parent had a policy to check the child zone (because
with the "not active" the parent could tell that the key just won't be
there).

A


--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se