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


To: EPP Provreg <ietf-provreg@cafax.se>
From: James Gould <jgould@verisign.com>
Date: Mon, 15 Feb 2010 19:26:01 -0500
In-Reply-To: <C79AE64E.37620%jgould@verisign.com>
Sender: owner-ietf-provreg@cafax.se
Thread-Index: Acp4F0PEFpQxGDTfOkWVMDcpTV7R9gyuHd/LAEtXUTgAqGFWHw==
Thread-Topic: draft-gould-rfc4310bis-04.txt Submitted for Review
User-Agent: Microsoft-Entourage/12.23.0.091001
Subject: [ietf-provreg] Re: draft-gould-rfc4310bis-04.txt Submitted for Review

Title: Re: draft-gould-rfc4310bis-04.txt Submitted for Review
All,

I haven’t heard any feedback on the idea of adding a client specified ttl value and an optional server ttl returned in the info response used in a similar fashion as the maxSigLife element.  The use case I see for this is allowing the client to determine what the ttl is for the DS RRset and the RRSIG resource record and for the client to have the option of decreasing the ttl in support of a DNS hosting transfer, which could be part of a sponsorship transfer.  To enable the DNS hosting transfer of a DNSSEC enabled domain without going insecure by removing the DS records, the losing DNS hosting provider needs to be capable of accepting the gaining DNS hosting provider’s public keys and the gaining DNS hosting provider’s DS needs to be added to the parent zone.   The switching of the name servers has to wait for the longest of the ttl’s (child and parent zone) to account for DNS caching, so having visibility of the ttl of the DNSSEC resource records of the server and to have the capability to adjust the ttl (down during the transfer) could help with the DNS hosting transfer process.  If such a feature needs to be added to rfc4310bis, I need to receive feedback early this week to be included in the rfc4310bis 05 draft.  I plan on publishing the rfc4310bis 05 draft on Wednesday that includes all of the feedback received so far.

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: James Gould <jgould@verisign.com>
Date: Fri, 12 Feb 2010 11:04:46 -0500
To: EPP Provreg <ietf-provreg@cafax.se>
Conversation: draft-gould-rfc4310bis-04.txt Submitted for Review
Subject: Re: draft-gould-rfc4310bis-04.txt Submitted for Review

All,

I forgot about one item brought up by Klaus in a prior posting related to inclusion of ttl in rfc4310bis.  What does the list feel about the need for adding support for an optional client specified ttl value and an optional server ttl returned in the info response used in a similar fashion as the maxSigLife, meaning directly under the secDNS:create, secDNS:infData, and under the secDNS:chg of the secDNS:update?  From my perspective this might be useful in the handling of DNS hosting transfers, where the Registrant can request for a reduced ttl for the DS RRset and the RRSIG resource record when moving the DNSSEC enabled domain to another DNS hosting provider.  The DNS hosting provider could obviously be another Registrar as part of a sponsorship transfer.  

Any thoughts to this is greatly appreciated.  

According to the AD the last call review period will be extended and should be on the IESG telechat agenda for March 4th, so I would like to incorporate as much feedback as possible to the 04 draft in a soon to follow 05 draft.  

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: James Gould <jgould@verisign.com>
Date: Wed, 10 Feb 2010 23:07:31 -0500
To: EPP Provreg <ietf-provreg@cafax.se>
Conversation: draft-gould-rfc4310bis-04.txt Submitted for Review
Subject: draft-gould-rfc4310bis-04.txt Submitted for Review

All,

I submitted 04 of the draft.  The official draft is available at the URL below:

http://www.ietf.org/id/draft-gould-rfc4310bis-04.txt

There are many updates from 03 described in Appendix A based on the feedback on the list and privately.  These changes are substantial, so please review it and provide me with your feedback as soon as possible.  

I did not include anything in 04 related to Eduardo’s active flag request based on the variety of feedback on the provreg list that shows that it’s not ready for inclusion in rfc4310bis.  I encourage that the discussions continue on the list for possible inclusion in a future draft.

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.


Home | Date list | Subject list