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

[Andrew Sullivan <ajs@shinkuro.com>]

On Wed, Nov 04, 2009 at 09:43:23AM -0500, James Gould wrote:
> All,
> 
> Before we continue to go around in circles, can I propose an option that
> addresses most of everyone¹s concerns, where the following would be met?
> 
> 1. XML schema is backward compatible

What do you mean by this exactly?  It seems that you are proposing
changing the schema in such a way that the schema is not actually
backward compatible, because you want to make it protocol-impossible
for someone to delete all DS data just by using the keyTag.  I think
that requires that the schemas are formally incompatible.  Doesn't it?

> 4. Support for a dsData and keyData primary interface.  Only one primary
> interface should be supported by the server.

I think I don't know what "primary interface" means in the above.  If
you mean that the I-D should say something like "A server MUST accept
either dsData or keyData, and SHOULD NOT accept both," it makes sense
to me.

> 5. Remove support for the wildcard delete of dsData in the rem by just using
> the keyTag with a clear statement (i.e. Server must return error if the
> keyTag matches multiple DS records) in the specification.  From my
> perspective and I believe a couple others this is a key issue that must be
> addressed.    

Nobody has yet responded to my contention that this is a policy
matter, and shouldn't be required by the protocol.  You don't happen
to have a deployed system using 4310 yet, so it isn't a concern to
you, but it seems to me that there are people who do have such
deployed systems, and the above requirement effectively requires them
to have a flag day.  Why does that need to be a protocol mandate, when
we can do it with registry policy?

> 6. Clarity in the specification on the use of the chg as a replace or a
> ³change all².   

I think the I-D I circulated already contains such language.

> 7. Clarity around the corner case of a client attempting to add and remove
> the same dsData or keyData in a single command.  This must result in an
> error from the server. 

Why?  In the mainline EPP specification, if you remove and add the
same name servers in a single command, it doesn't cause an error.  (I
know this because misguided registrars used to do it all the time in
an effort to get the "primary" name server "listed first".)  It's a
waste of bandwidth, but since EPP is idempotent it should have no
effect, right?

> Additionally an error must be returned if the client
> tries to remove dsData or keyData that does not exist or tries to add dsData
> or keyData that already exists.

These are already errors, I think, 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