To:
EPP Provreg <ietf-provreg@cafax.se>
From:
Andrew Sullivan <ajs@shinkuro.com>
Date:
Tue, 3 Nov 2009 17:20:47 -0500
Content-Disposition:
inline
In-Reply-To:
<7C4B2203-CB8E-4DAC-869B-334D36ADB8A3@afilias.info>
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 03:32:37PM -0600, Howard Eland wrote: > > From this perspective, the only reason to continue to support :chg would > be because others are currently using it. > Because of this, I support the deprecation of :chg for DS records. The conclusion seems not to follow from the premise. We do not know whether anyone is using chg. If we remove support, then we might break someone who doesn't know to follow the list of a long-closed WG. What benefit is there in removing support? > I've read Andrew's argument about keeping only the keyTag as part of the > rem, but I'm concerned about making the text and XML correct with > supporting only a keyTag IFF it removes one DS record, ELSE returns an > error that specifies the problem, and possibly suggests adding all other > parameters. Why do we need to do this? If registries want to make a policy that they won't accept changes with only the keyTag, I think we ought to make it possible to do that. I don't see any reason at all that the protocol should require one behaviour or another, however. And again, without allowing keyTag-only operation, we're forcing on anyone who has already implemented 4310 a flag day cutover: on that day, all the old clients need to stop. No? >> 3. Support for the combination of add and rem > > Yes, provided the text clearly states that only one outcome can occur. > This can mean doing all adds first, or all removes first. Of course, all > adds can occur in any order, as can all removes. Allowing policy to > dictate how this works would be mean that registrars would have to > support both. I don't think I understand your remark here. I thought the idea was that we make this a sequence, such that the outcome is whatever that sequence of operations would be. No? 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