To:
EPP Provreg <ietf-provreg@cafax.se>
From:
Andrew Sullivan <ajs@shinkuro.com>
Date:
Tue, 3 Nov 2009 11:23:07 -0500
Content-Disposition:
inline
In-Reply-To:
<C715BE78.3598A%jgould@verisign.com>
Mail-Followup-To:
Andrew Sullivan <ajs@shinkuro.com>,EPP Provreg <ietf-provreg@cafax.se>
Sender:
owner-ietf-provreg@cafax.se
User-Agent:
Mutt/1.5.18 (2008-05-17)
Subject:
Re: [ietf-provreg] Anyone working on 4310-bis?
On Tue, Nov 03, 2009 at 11:03:20AM -0500, James Gould wrote: > 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. The latter is certainly not true: by policy one could decide to allow simple keyTag uses, since in just about every case the keyTag is actually going to be enough. There is a problem when one is changing algorithms, for instance, but that doesn't happen very often. The key thing in preparing the protocol is not to make it as simple as possible, but to make it as simple as possible without excluding any reasonable operational model. Competent experts in the field can legitimately disagree about what is a "reasonable operational model", and I'm particularly keen not to change anything that just breaks deployed and running code in the interests of simplicity. > 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. I agree it's different, but there is a strong data-source argument that the registry is the correct generator of the DS record, because the DS is authoritative in the parent side. This is different from the usual NS case, where the record is identical on both sides of the zone cut. 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