Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted forReview

[James Gould <jgould@verisign.com>]

Title: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted forReview

Andrew,

I thought about the concept of replace a little bit more, and I generally agree that it’s better to use the secDNS:rem for removals.  I believe that to fully support the concept of a set / replace with secDNS:chg that the zero or more case should be supported.  Limiting it to the one or more case is kind of like creating a list that must have at least one element, which doesn’t sound like a very useful list.  The risk of removing all data holds from the Registrar web site independent of what is supported by the protocol, since the Registrar web site could translate an empty web form to mean remove all.  Remove all could be done as well via secDNS:rem.

I propose adding the zero or more case to the draft for secDNS:chg.  Please respond to the list or to me privately if you support this or don’t support this along with any reasons.  

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: Fri, 11 Dec 2009 17:07:09 -0500
To: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted forReview

On Fri, Dec 11, 2009 at 03:51:42PM -0500, James Gould wrote:

> corner case that is not covered in the current schema is replacing all DS or
> Key Data with nothing, meaning remove all.  I prefer that the client
> explicitly specify what should be added or removed via the secDNS:add and
> secDNS:rem, but the secDNS:chg could be updated to allow an empty
> secDNS:chg.

That sounds to me like a foot-gun loaded for bear.  I think what will
happen is that someone will have some nasty bug that fails to get the
new data into place (think "empty webform gets submitted by
fat-fingered iphone user" or even worse, "webform bug doesn't get POST
data properly from client") and submits a syntactically-legal empty
"new state" dataset.  Poof!  Instant DS deletion.

Now, normally I'd argue that the above is policy, not protocol, except
that I dislike very much the habit of overloading "no data" to also
mean "replace data with NULL" (we recovering database geeks just see
this sort of thing everywhere).  So I'd say if you want to remove
something, you have to remove it, not change it to "empty".

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