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


To: James Gould <jgould@verisign.com>
Cc: Eduardo Duarte <eduardo.duarte@fccn.pt>, EPP Provreg <ietf-provreg@cafax.se>, "'WG-DNS'" <wg-dns@fccn.pt>
From: Patrik Fältström <paf@cisco.com>
Date: Tue, 26 Jan 2010 06:56:24 +0100
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
In-Reply-To: <C7838D7E.37033%jgould@verisign.com>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: [ietf-provreg] Revision of 4310

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.

   Patrik

On 26 jan 2010, at 00.03, James Gould wrote:

> Eduardo,
> 
> I don't believe this was discussed, but what is the expected behavior of the
> server?  Is the use case that the clients would pre-publish the DS as active
> / inactive to the server, and the server would in turn only publish the
> active DS data?  The current draft has the server publish all passed DS
> information, so the client would add / remove DS data instead of
> pre-publishing and activating / deactivating them.  Now all records are
> considered active.  Adding an additional attribute would be somewhat
> challenging, since it would require the client to add and remove the same
> DS, but with the activity flag set to a different value on the add.  This is
> a corner case that came up with changing the maxSigLife.
> 
> -- 
> 
> 
> 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: Eduardo Duarte <eduardo.duarte@fccn.pt>
>> Date: Mon, 25 Jan 2010 14:56:53 +0000
>> To: EPP Provreg <ietf-provreg@cafax.se>
>> Cc: 'WG-DNS' <wg-dns@fccn.pt>
>> Subject: [ietf-provreg] Revision of 4310
>> 
>> Hello,
>> 
>> I work for the .PT ccTLD and I'm starting to add the DNSSEC extension
>> under our EPP implementation.
>> For doing this I'm following the the new revision of the 4310 RFC and I
>> was wondering something after reading it...
>> 
>> On our implementation of DNSSEC a domain can have multiple DS keys
>> associated were some are active and other are in an inactive state.
>> On the secDNS.xsd I didn't see any way to have multiple keys send in the
>> info command and have a way to show if they are active or not.
>> 
>> Was this matter discuss on the list already!?
>> 
>> If no can I propose a small change in XSD (I know that is probably to
>> late for that....). My suggestion is to add a Active/Non-Active field on
>> the DSdataType so the definition changes to the following:
>> <complexType name="dsDataType">
>> <sequence>
>> <element name="keyTag" type="unsignedShort"/>
>> <element name="alg" type="unsignedByte"/>
>> <element name="digestType" type="unsignedByte"/>
>> <element name="digest" type="hexBinary"/>
>> <element name="maxSigLife" type="secDNS:maxSigLifeType" minOccurs="0"/>
>> <element name="keyData" type="secDNS:keyDataType" minOccurs="0"/>
>> <element name="active" type="boolean" minOccurs="0"/>
>> </sequence>
>> </complexType>
>> 
>> Thanks and best regards,
>> 
>> Eduardo Duarte
>> 
>> 
>> 
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>> List run by majordomo software.  For (Un-)subscription and similar details
>> send "help" to ietf-provreg-request@cafax.se
>> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> List run by majordomo software.  For (Un-)subscription and similar details
> send "help" to ietf-provreg-request@cafax.se
> 


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


Home | Date list | Subject list