Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted for Review

From: James Gould <[email-masked]>
Date: Fri, 11 Dec 2009 15:51:42 -0500

Patrik,

Thanks for the feedback.  The secDNS:chg should be able to handle the use
case that you describe, since secDNS:chg is a full replace.  Removing all
existing and setting the new DS or Key Data is handled by secDNS:chg.  The
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.  Below is the schema update needed to allow secDNS:chg to be
empty.  This change is also backward compatible, so the question is whether
it meets the need and whether it is a good practice to include in the draft?
Any thoughts to this?

    <complexType name="chgType">
        <choice minOccurs="0">
            <element name="dsData" type="secDNS:dsDataType"
maxOccurs="unbounded"/>
            <element name="keyData" type="secDNS:keyDataType"
maxOccurs="unbounded"/>
        </choice>
    </complexType>

    <complexType name="updateType">
        <choice>
          <element name="chg" type="secDNS:chgType"/>
          <sequence>
            <element name="add" type="secDNS:dsOrKeyType" minOccurs="0"/>
            <element name="rem" type="secDNS:remType" minOccurs="0"/>
          </sequence>
        </choice>
        <attribute name="urgent" type="boolean" default="false"/>
    </complexType>

The sample command looks like:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
     epp-1.0.xsd">
  <command>
    <update>
      <domain:update
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
       domain-1.0.xsd">
        <domain:name>example.com</domain:name>
      </domain:update>
    </update>
    <extension>
      <secDNS:update urgent="1"
       xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
       xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0
       secDNS-1.0.xsd">
        <secDNS:chg/>
      </secDNS:update>
    </extension>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

-- 

JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
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: Patrik Fältström <[email-masked]>
Date: Fri, 11 Dec 2009 05:10:46 -0500
To: James Gould <[email-masked]>
Cc: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted for
Review

On 8 dec 2009, at 16.01, James Gould wrote:

> The draft meets the following goals that were previously sent to the list:
>
> 1. XML schema is backward compatible
> 2. Support for add and rem in the same command
> 3. Support for passing all four dsData attributes on a rem
> 4. Support for a dsData and keyData primary interface.  Only one primary
> interface should be supported by the server.
> 5. Remove support for the wildcard delete of dsData in the rem by just using
> the keyTag with a clear statement (i.e. Server must return error if the
> keyTag matches multiple DS records) in the specification.  From my
> perspective and I believe a couple others this is a key issue that must be
> addressed.   
> 6. Clarity in the specification on the use of the chg as a replace or a
> ³change all².  
> 7. Clarity around the corner case of a client attempting to add and remove
> the same dsData or keyData in a single command.  This must result in an
> error from the server.  Additionally an error must be returned if the client
> tries to remove dsData or keyData that does not exist or tries to add dsData
> or keyData that already exists.

I think the draft is good, and clarifies a number of things.

But, when adding things (as we are), I ask whether we can not add a feature
to the protocol that we use in .SE that actually make things a bit easier:

If a "rem" has a keytag of zero, then all keytags are removed.

That eliminates some situations (specifically after a transfer to a gaining
registrar) a number of info + multiple rem commands. One can "just" do "rem
keytag=0" followed by the add of the new keys. And, it also makes life
easier when doing a transfer to a registrar that do not support DNSSEC. They
"only" have to be able to do rem, keytag=9 on the domains they gain.

  Patrik

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

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 11 Dec 2009 17:07:09 -0500

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

> 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
[email-masked]
Shinkuro, Inc.

---

From: James Gould <[email-masked]>
Date: Fri, 11 Dec 2009 17:35:22 -0500

Andrew,

Thanks, that is my feeling as well.  I want to bring this up as an option,
but I believe that it¹s better to make updates explicit.  The gaining
Registrar can easily do an info to get the existing DS (or key data) and
then remove all of the DS (or key data) in a subsequent update explicitly
via secDNS:rem.  Any other thoughts to this?

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Andrew Sullivan <[email-masked]>
Date: Fri, 11 Dec 2009 17:07:09 -0500
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted
forReview

A

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 14 Dec 2009 11:19:54 -0500

On Mon, Dec 14, 2009 at 11:13:10AM -0500, James Gould wrote:
> 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.  

Well, my _real_ complaint is a data cleanliness/modelling issue.  I
hate having "no data" mean "null".  Only SQL geeks really get excited
about this sort of thing, however, and if others really want this I'm
not really going to object, since I don't have to run any systems that
use it.

A

---

From: James Gould <[email-masked]>
Date: Mon, 14 Dec 2009 11:13:10 -0500

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 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

A

---

From: Ulrich Wisser <[email-masked]>
Date: Mon, 14 Dec 2009 21:20:54 +0100

> 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.  

It does make life easier for many web application programmers. So I 
would like to second that change.

/Ulrich

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 15 Dec 2009 08:32:08 +0100

On 14 dec 2009, at 21.20, Ulrich Wisser wrote:

>> 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.  
> 
> It does make life easier for many web application programmers. So I would like to second that change.

I also think this is needed, or as I said earlier, any mechanism that make it easy for someone that do _not_ support 4310 to at least remove the DS data in the registry.

   Patrik

---

From: "Michael Young" <[email-masked]>
Date: Tue, 15 Dec 2009 07:54:31 -0500

Makes sense to me.

Michael Young 

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]] 
Sent: Tuesday, December 15, 2009 2:32 AM
To: Ulrich Wisser
Cc: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted
forReview

>> 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.  
> It does make life easier for many web application programmers. So I would
like to second that change.

I also think this is needed, or as I said earlier, any mechanism that make
it easy for someone that do _not_ support 4310 to at least remove the DS
data in the registry.

   Patrik