To:
Andrew Sullivan <ajs@shinkuro.com>, EPP Provreg <ietf-provreg@cafax.se>
From:
James Gould <jgould@verisign.com>
Date:
Wed, 25 Nov 2009 10:25:50 -0500
In-Reply-To:
<C73042A7.35F18%jgould@verisign.com>
Sender:
owner-ietf-provreg@cafax.se
Thread-Index:
AcpsaLMqgJIhsAXzRqCLdK3J/Sr8MgABIj9bAF2VWLk=
Thread-Topic:
[ietf-provreg] Is there a 4310-bis document?
User-Agent:
Microsoft-Entourage/12.20.0.090605
Subject:
Re: [ietf-provreg] Is there a 4310-bis document?
All, Išve attached a proposed XML schema based on hitting on points 1, 2, 3, and 5 from the list below. Points 4 and 6 will be addressed in the draft. Please review the XML schema and let me know if there are any issues. 1. Maintains XML schema backward compatibility 2. Support the ability to add and remove in the same command 3. Support the ability to specify either keyTag or all of the dsData attributes for a remove. 4. Add clarity around the chg functioning as a replace. 5. Add support for a keyData or a dsData interface for Registries that intend to manage the DS data generation. I intend to have the XML schema support both, but to specify that the server MUST support only one or the other. 6. Add a SHOULD statement around the server returning an error for wildcard deletes to address one of the main concerns around unexpected side effects of the rem matching multiple DS records with the same keyTag. Are there any other points that need to be addressed? I made the dsData (DS Data Interface) and keyData (Key Data Interface) mutually exclusive, so by the XML schema there is no mixing of the two interfaces while maintaining backward compatibility with RFC 4310. I'm really looking for feedback from the registries planning to support the Key Data Interface. I'm assuming that with the Key Data Interface that no DS data is passed (command or response) since it's being completely managed by the server. Adding DS data to the Key Data Interface adds complexities since the server could create multiple DS records for an individual key. I also assume that the server must choose either the DS Data Interface or the Key Data Interface to make the protocol clear to the clients. Supporting the Key Data Interface is a significant change to the draft so I want to ensure that it is meeting the requirements for those who plan on using it. 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: Mon, 23 Nov 2009 13:46:15 -0500 To: Andrew Sullivan <ajs@shinkuro.com>, EPP Provreg <ietf-provreg@cafax.se> Conversation: [ietf-provreg] Is there a 4310-bis document? Subject: Re: [ietf-provreg] Is there a 4310-bis document? Andrew, I can take the task of creating a draft update based on a compromise discussed on this list that meets the following points. Can you forward me the draft XML that you created? 1. Maintains XML schema backward compatibility 2. Support the ability to add and remove in the same command 3. Support the ability to specify either keyTag or all of the dsData attributes for a remove. 4. Add clarity around the chg functioning as a replace. 5. Add support for a keyData or a dsData interface for Registries that intend to manage the DS data generation. I intend to have the XML schema support both, but to specify that the server MUST support only one or the other. 6. Add a SHOULD statement around the server returning an error for wildcard deletes to address one of the main concerns around unexpected side effects of the rem matching multiple DS records with the same keyTag. I believe the best route is to keep the interface as close as possible to RFC 4310, but with updates to address the main interface issues. There are systems in Production and will be in Production shortly that should have a smooth migration path to the updated draft. Any suggestions that the list has with any of these items, please let me know. Once I have the draft created Išll send it out the list for review. 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: Andrew Sullivan <ajs@shinkuro.com> Date: Mon, 23 Nov 2009 12:48:33 -0500 To: EPP Provreg <ietf-provreg@cafax.se> Subject: Re: [ietf-provreg] Is there a 4310-bis document? On Mon, Nov 23, 2009 at 10:18:15AM -0500, Edward Lewis wrote: > I'm curious...is anyone preparing a document? I have a -00 draft (I mailed it at least once to the list), but it didn't meet several people's needs. My conclusion was that the draft needed almost a complete rewrite, and this is no longer just an update but a complete new specification. I haven't had a chance to go back to it. If someone is dying to take over, I have XML that can be used. I'm happy to have my name dropped from the list in that case. > (consider it). Considering others are in production, is it a given that > there will be backwards compatibility? There will not be schema compatibility if we go the way currently proposed. If we go that way, it might be that old clients will work fine with new servers. James seemed to suggest at one point that during a transition period, the way to get there would just be for servers or clients or both to ignore parts of the new protocol. This answer makes my teeth hurt, but maybe we can get something cleaner. 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