Re: 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
[email protected]
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 <[email protected]>
Date: Tue, 26 Jan 2010 09:06:17 -0500
To: EPP Provreg <[email protected]>
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
[email protected]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to [email protected]