Re: 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
[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: Ulrich Wisser <[email protected]>
Date: Fri, 5 Feb 2010 08:06:07 -0500
To: EPP Provreg <[email protected]>
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 [email protected]