Re: off-list was Re: [ietf-provreg] Revision of 4310

[James Gould <jgould@verisign.com>]

Title: Re: off-list was Re: [ietf-provreg] Revision of 4310

Eduardo,

I’m getting a little bit confused with the request.  Can you describe the use case step-by-step on the usage of the active flag?  The current RFC and draft assumes that the server publishes the DS as soon as possible after receiving it from the client, where it would be considered active (with some delay to propagate) from a provisioning perspective.  Is there additional server-side logic that I’m not aware of?  

Thanks,
 

-- 


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: Wed, 27 Jan 2010 06:08:55 -0500
To: EPP Provreg <ietf-provreg@cafax.se>
Cc: WG-DNS <wg-dns@fccn.pt>
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310

Hello,

First of all sorry not to have contributed yesterday but I had no time
to read all the emails... :(

Well when I was thinking of this flag I was thinking that it would mean
if the key is publish in the parent zone and I was not thinking to much
on the create/update commands but more on the info... :P
On our work model a domain can have more then one key associated with
domain and they can be in a active or inactive state where active means
publish or unpublished  in the parent zone.
When adding a key I dont see the problem of it becoming automatically
publish in the parent zone and the old key to be unpublished as soon at
is expire or remove.  But lets say the owner of the domain keep just
adding keys! After a while if in the info command you send back all the
keys associated with the domain you will not have a good hint of wich
ones are publish... Or if a domain change onwer also will be a bit
difficult to understand witch of the keys are publish without consulting
directly the DNS server...
Also you can say for me to send on the info command just the active key,
but then I will be not sending all the associated data with the domain...
So to cover this ground of sending all the data back and the state of
the DS I proposed the active/inactive flag, that I supposed that is
backwards compatible.

I know that some other registries use this model for managing the client
keys and that was why I asked if this was already been discussed...

Best regards,

Eduardo Duarte


Jaap Akkerhuis wrote, On 26-01-2010 22:53:
>      Was meant to be off-list.  Because I'm diving into the details of
>      DNSSEC itself.  (And not saying anything new.)
>
>      To come back to EPP, I think we need to revisit "active/inactive" and
>      the implications it has to a registry.
>
> Well, since Eduardo Duarte from the .PT registry proposed it, maybe
> he should starts to explain what problems he wants to solve with this.
>
>       jaap
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 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