Re: [ietf-provreg] Anyone working on 4310-bis?

[James Gould <jgould@verisign.com>]

Title: Re: [ietf-provreg] Anyone working on 4310-bis?

Andrew,

I understand that it can be made up to registry policy, but I want to ensure that we don’t make it more difficult for the clients to interface with servers applying different interface policies (support for chg, support for just keyTag, support for add and rem, and support for keyData interface) with potentially little extra value.  Supporting add and rem in a single command pretty much deprecates chg and supporting rem with all DS attributes pretty much deprecates the use of just the keyTag.  I don’t have heartburn to leaving the deprecated elements in the specification for backward compatibility, but that would be the only reason they should be left in.  Support for both the dsData and keyData interfaces is a fundamental different interface similar to the difference between hostAttr and hostObj in the domain specification, so I don’t support adding extra options to the specification that can lead to confusion if there is not a compelling reason to do so.  For our registries the dsData interface is sufficient, so I would like to understand the real driver behind the keyData interface and whether this is being driven by Registrars.   

-- 


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: Tue, 3 Nov 2009 10:04:22 -0500
To: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

On Mon, Nov 02, 2009 at 11:46:00AM -0400, James Gould wrote:
> Howard,
>
> So if we ³go to the well once² without backward compatibility support, the
> schema would do the following:
>
> 1. Remove support for the chg
> 2. Remove support for rem with just keyTag

I see no reason whatever to make those changes in the protocol.  That
is a conflation of policy and protocol.  There might be good reasons
for server operators not to allow such combinations, and therefore I
think we should make it possible for a server operator to refuse such
operations.  But we shouldn't remove them from the protocol.

> 3. Support for the combination of add and rem

This seems fine to me, and when I update the draft the next time I'll
make the change so that this is possible.  Now that I understand how
sequence works, this is an obvious improvement.

> 4. Specify all of the DS information (keyTag, alg, digestType, and digest)
> on an add and rem.

I am willing to make this change.  Obviously, using all of them is
redundant (if we start having hash collisions, there's going to be
bigger problems with DNSSEC than getting the DS record into the parent
via EPP), but the symmetry might make the coding easier, and it's not
that much more data.  That said, I don't think we need to require this
(see above).

> As far as supporting a keyData interface and dsData interface to the clients
> , I believe that client-side software (SDK¹s and utilities) should be
> available for the client to generate the DS instead of pushing it to the
> server-side.  With the dsData interface, the client has maximum flexibility,
> the load is distributed to the client-side, and the registries can provide
> one consistent interface.  It would be good to hear from the Registrars
> related to supporting two different models across tkeyhe DNSSEC registries.

Well, there's nothing wrong with adding the feature to the protocol as
such.  The question is really whether anybody really wants this.

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