To:
EPP Provreg <ietf-provreg@cafax.se>
From:
Howard Eland <heland@afilias.info>
Date:
Wed, 25 Nov 2009 13:26:36 -0600
In-Reply-To:
<C732B6B0.35FBD%jgould@verisign.com>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: [ietf-provreg] Is there a 4310-bis document?
Thanks for this, JG. I'll not have a chance to review before the US holiday, but I will next week. -Howard On Nov 25, 2009, at 9:25 AM, James Gould wrote: > 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 > > > > <secDNS-1.0.xsd> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se