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

[Andrew Sullivan <ajs@shinkuro.com>]

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