Re: RFC4310bis document writeup

Ray,

The last sentence ³The server MUST return an EPP error result code of 2306
if the server receives a command using an unsupported interface³ of section
4 was added to address your feedback below.  The remainder of the updates in
section 4 was made to address Alex¹s Nit review feedback.

> Also, I note that §4 says that a server MUST support either <secDNS:dsData> or
> <secDNS:keyData>, but not both (unless in transition from one to the other).
> However I can find no guidance on what should happen if the client sends the
> wrong one.  The schema is clear that it's a choice, but that only affects
> individual messages, and doesn't reflect the server's capabilities.


> In particular the newly documented requirement that EPP clients have to
> "remove all" and then re-insert DNSSEC data in order to migrate from one
> format to the other on a _per_domain_ basis may have significant design and
> implementation overhead that was not previously anticipated.

The use of the ³remove all² was added as one option to migrate from one
interface to a new interface.  This is defined as a MAY and not a MUST, so
it is not a requirement.   There are certainly other options, but we don¹t
want to get into a position where the server has both client specified DS
and server-generated DS for the same domain.  The use of ³remove all² along
with adding using the new interface will ensure that there is no mixing on a
per-domain.   The sentence ³The server MUST support the use of only one form
of interface except  during a transition period during which time the server
MAY support both² in section 4 of ­06 was expanded to the second paragraph
in section 4 of ­06 to clarify it based on Alex¹s feedback.



-- 


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: <[email protected]>
Date: Thu, 4 Mar 2010 04:08:16 -0500
To: Olafur Gudmundsson <[email protected]>
Cc: <[email protected]>, EPP Provreg <[email protected]>
Subject: Re: [ietf-provreg] RFC4310bis document writeup


> Version 07 a nits pass

Olafur, 

There's actually some substantial new text in §4 introduced between the -06
and the -07  versions to address my comments about <secdns:dsData> vs
<secdns:keyData>. 

In particular the newly documented requirement that EPP clients have to
"remove all" and then re-insert DNSSEC data in order to migrate from one
format to the other on a _per_domain_ basis may have significant design and
implementation overhead that was not previously anticipated.

I'm still trying to grok the implications of this new text, and am
consulting with our EPP implementors as to whether this is considered too
arduous a requirement to be written in stone in the draft.

kind regards, 

Ray 

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email protected], t: +44 1865 332211