Re: [ietf-provreg] XML Schema versioning in 4310bis

[James Gould <jgould@verisign.com>]

Title: Re: [ietf-provreg] XML Schema versioning in 4310bis

Klaus,

Thanks for responding to this topic.  Below is my feedback to the feedback.

>> when discussing 4310bis we did focus very much on backward
>> compatibility. Which isn't necessarily a bad thing. But by making the
>> old style rem command optional we break exactly the one thing we were
>> aiming for.
> 
> Hmm. I am quite sure that the current version of 4310bis allows the processing
> of all valid 4310 requests.

There was much discussion related to supporting the old style secDNS:rem with secDNS:keyTag on the list.  The following text in the draft directly addresses the issue according to a compromise from this list:

> <secDNS:keyTag> element MUST contain a key tag value as described in section 5.1.1 of RFC 4034 [6]. Removing all DS information can remove the ability of the parent to secure the delegation to the child zone. The server SHOULD return an EPP error result code of 2305 if more than one DS record matches the <secDNS:keyTag>. <secDNS:dsData> should be used by the client if there is more than one DS record with the same <secDNS:keyTag>. 

I would like to continue with what was compromised in addressing the issue of using the non-unique secDNS:keyTag.  Is this not an acceptable solution?  

>> 
>> After some discussions with registrars and my colleagues, we came to the
>> conclusion that a new URI would be a better solution. The server could
>> support both versions of the protocol (and therefor not break old
>> clients) and clients would know which interface to use.
> 
> Agreed.

Ok, it looks like the feedback is to use a different URI.  I can go with this.  If anyone disagrees, please respond to the list or to me privately.  I can go with urn:ietf:params:xml:ns:secDNS-1.1 as proposed by Bernie.  

>> 
>> If we change the URI, I propose to drop backward compatibility and get
>> rid of the old style rem.
> 
> This is a valid option, but it throws us back nearly to the beginning of the
> discussion. But if it's worth...

I don’t believe that there is a compelling need to open up pandora’s box for this item.  The goal is to address the main issues with RFC 4310, which the draft I believe does.  I’ll drop the URI backward compatibility goal (or I guess sub-goal).  

-- 


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: Klaus Malorny <Klaus.Malorny@knipp.de>
Date: Wed, 27 Jan 2010 09:53:18 -0500
To: Ulrich Wisser <liste@publisher.de>
Cc: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis

On 27/01/10 09:53, Ulrich Wisser wrote:
> Hi,
>
Hi,

> when discussing 4310bis we did focus very much on backward
> compatibility. Which isn't necessarily a bad thing. But by making the
> old style rem command optional we break exactly the one thing we were
> aiming for.

Hmm. I am quite sure that the current version of 4310bis allows the processing
of all valid 4310 requests.

>
> After some discussions with registrars and my colleagues, we came to the
> conclusion that a new URI would be a better solution. The server could
> support both versions of the protocol (and therefor not break old
> clients) and clients would know which interface to use.

Agreed.

>
> If we change the URI, I propose to drop backward compatibility and get
> rid of the old style rem.

This is a valid option, but it throws us back nearly to the beginning of the
discussion. But if it's worth...

>
> /Ulrich

Regards,

Klaus
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se