To:
James Gould <jgould@verisign.com>
CC:
Klaus Malorny <Klaus.Malorny@knipp.de>, EPP Provreg <ietf-provreg@cafax.se>
From:
Ulrich Wisser <liste@publisher.de>
Date:
Thu, 28 Jan 2010 11:22:31 +0100
In-Reply-To:
<C785E4EA.37136%jgould@verisign.com>
Sender:
owner-ietf-provreg@cafax.se
User-Agent:
Thunderbird 2.0.0.23 (Macintosh/20090812)
Subject:
Re: [ietf-provreg] XML Schema versioning in 4310bis
Hi James, [...] > There was much discussion related to supporting the old style secDNS:rem > with secDNS:keyTag on the list. The following text in the draft > directly addresses the issue according to a compromise from this list: > > <secDNS:keyTag> element MUST contain a key tag value as described in > section 5.1.1 of RFC 4034 *[6]*. Removing all DS information can > remove the ability of the parent to secure the delegation to the > child zone. The server SHOULD return an EPP error result code of > 2305 if more than one DS record matches the <secDNS:keyTag>. > <secDNS:dsData> should be used by the client if there is more than > one DS record with the same <secDNS:keyTag>. > > > I would like to continue with what was compromised in addressing the > issue of using the non-unique secDNS:keyTag. Is this not an acceptable > solution? How could I miss this? If a client (our own registrar currently does) send two DS records per key (SHA-1 and SHA-256), these posts could not be deleted with they old style <rem/>. /Ulrich -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se