Re: [ietf-provreg] Pandoras box - or not!? you decide

[James Gould <jgould@verisign.com>]

Title: Re: [ietf-provreg] Pandoras box - or not!? you decide

Ulrich,

Thanks for stepping forward with your proposal.  We’ve come a long way which is one reason to stay the course, but I would like to hear from the list feedback to Ulrich’s proposal.  I don’t believe the changes being requested are all that large, but they are a significant shift from backward compatibility which was broken with the URI change.  I provide feedback to your proposals below.  I certainly don’t want to entertain truly opening up Pandora's Box with a laundry list of new features and extend the time getting this update out for servers to implement to.  

> 1. Drop old style <secDNS:rem/>
> There is no need to support a broken specification in the new version.
> Servers looking for backward compatibility can use version 1.0.

All we’re talking about here is removing support for the <secDNS:rem> with the <secDNS:keyTag>.  The issue with use of the <secDNS:rem> and <secDNS:keyTag> (wildcard delete) is mitigated in the text, but if no one intends to support the old model than it can be removed.  

> 2. Redefine the <secDNS:chg/> to match the semantics used in all other
> EPP documents.
> The usual definition of add/rem/chg for EPP is that add will add things,
> rem will remove things and chg will update things that can't be added or
> removed. E.g. the registrant for a domain can only be changed, ns
> records can only be added or removed not changed.
> That would mean <secDNS:chg/> could no longer be used to add or remove
> ds records. But chg could be used to update maxSigLife.
> This would also mean to drop maxSigLife from dsData and keyData
> interface. And of course maxSigLife can't be added or removed.

I already moved the secDNS:maxSigLife element out of the secDNS:dsData and secDNS:keyData elements based on feedback from the list and since I agree that maxSigLife is not an attribute of the secDNS:dsData or secDNS:keyData but an attribute of the RRSIG which is at the domain level.  If we don’t add the secDNS:childKeyPublished element to secDNS:dsData and secDNS:keyData as described in option #3 of my “off-list was Re: [ietf-provreg] Revision of 4310” posting on the list there are no attributes to update under secDNS:dsData and secDNS:keyData.  Based on this the secDNS:chg could be removed all together since it really is just an alternative for the secDNS:add and secDNS:rem.  If there is an client updatable attribute under secDNS:dsData and secDNS:keyData then secDNS:chg would be needed.  The only case right now that I’m aware of is the secDNS:childKeyPublished element that is being discussed on the list.  

Removing is a lot easier than adding to the draft, but if there are any servers intending to use the old features than they will have to stay.  Our servers will most likely have to support 1.0 and 1.1, but I’m assuming that the bulk of the clients would opt to use 1.1.  Since our business logic would have to support both models, including the old model in 1.1 is not hard to support but is certainly not a hard requirement.  I generally agree that your proposals would make the draft simpler and more consistent with the other EPP RFC’s.  I really want to hear from the list on this to determine if we keep the draft as is or if we remove one or both (<secDNS:rem> with <secDNS:keyTag> and use of the <secDNS:chg>) of the old models.  Send feedback to the list or to me privately.

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: Ulrich Wisser <liste@publisher.de>
Date: Fri, 5 Feb 2010 08:06:07 -0500
To: EPP Provreg <ietf-provreg@cafax.se>
Subject: [ietf-provreg] Pandoras box - or not!? you decide

Hi,

may proposal maybe not the most popular, but anyway ...

Now that we will change the URN we could make this extension actually
reflect the behavior of EPP in general. We already have found an
inconsistency in the extension for maxSigLife. I propose the following
changes.

1. Drop old style <secDNS:rem/>
There is no need to support a broken specification in the new version.
Servers looking for backward compatibility can use version 1.0.

2. Redefine the <secDNS:chg/> to match the semantics used in all other
EPP documents.
The usual definition of add/rem/chg for EPP is that add will add things,
rem will remove things and chg will update things that can't be added or
removed. E.g. the registrant for a domain can only be changed, ns
records can only be added or removed not changed.
That would mean <secDNS:chg/> could no longer be used to add or remove
ds records. But chg could be used to update maxSigLife.
This would also mean to drop maxSigLife from dsData and keyData
interface. And of course maxSigLife can't be added or removed.

I know that these are no minor changes. And they most probably go beyond
the initial scope of the intended update to 4310. But I would like to
ask you to consider my proposal anyway. We have the chance to fix this
extension and I would like us to at least try to aim for the same
quality as the other EPP documents.

/Ulrich




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