Re: XML Schema versioning in 4310bis

Ulrich,

> 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/>.

That is correct as long as the server does what is recommended (SHOULD) by
the draft.  The client should use the secDNS:dsData with a secDNS:rem to
explicitly specify which DS to remove.  Does this address your concern?

-- 


JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email protected]
Direct: 703.948.3271
Mobile: 703.628.7063

 
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or
Registry  Sensitive information intended solely for the recipient and, thus
may not be  retransmitted, reproduced or disclosed without the prior written
consent of  VeriSign Naming and Directory Services.  If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy.  Thank you.



From: Ulrich Wisser <[email protected]>
Date: Thu, 28 Jan 2010 05:22:31 -0500
To: James Gould <[email protected]>
Cc: Klaus Malorny <[email protected]>, EPP Provreg
<[email protected]>
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