Re: 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
> [email protected]
> 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 <[email protected]>
> Date: Mon, 23 Nov 2009 13:46:15 -0500
> To: Andrew Sullivan <[email protected]>, EPP Provreg <[email protected] 
> >
> 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
> [email protected]
> 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 <[email protected]>
> Date: Mon, 23 Nov 2009 12:48:33 -0500
> To: EPP Provreg <[email protected]>
> 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
> [email protected]
> Shinkuro, Inc.
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 
> =-=-=-
> List run by majordomo software.  For (Un-)subscription and similar  
> details
> send "help" to [email protected]
>
>
>
> <secDNS-1.0.xsd>


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to [email protected]