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


To: <Ray.Bellis@nominet.org.uk>, Olafur Gudmundsson <ogud@ogud.com>
CC: <iesg@ietf.org>, EPP Provreg <ietf-provreg@cafax.se>
From: James Gould <jgould@verisign.com>
Date: Thu, 04 Mar 2010 07:51:15 -0500
In-Reply-To: <OF243C1A54.4DCC81EB-ON802576DC.00311330-802576DC.00323207@nominet.org.uk>
Sender: owner-ietf-provreg@cafax.se
Thread-Index: Acq7fW1j0T7JVRjdQAqpnHgt8SA35QAG/K1e
Thread-Topic: [ietf-provreg] RFC4310bis document writeup
User-Agent: Microsoft-Entourage/12.23.0.091001
Subject: Re: [ietf-provreg] RFC4310bis document writeup

Title: Re: [ietf-provreg] 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
jgould@verisign.com
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: <Ray.Bellis@nominet.org.uk>
Date: Thu, 4 Mar 2010 04:08:16 -0500
To: Olafur Gudmundsson <ogud@ogud.com>
Cc: <iesg@ietf.org>, EPP Provreg <ietf-provreg@cafax.se>
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: ray@nominet.org.uk, t: +44 1865 332211







Home | Date list | Subject list