[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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


Home | Date list | Subject list