RE: [ietf-provreg] secDNS-1.1: use of only one form of interface

["Michael Young" <myoung@ca.afilias.info>]

I'll keep my comments simple, Chris has a very valid point, there are other
examples of what he's referring to, .ZA comes to mind for instance.

Michael Young

-----Original Message-----
From: Chris Wright [mailto:chris@ausregistry.com.au] 
Sent: September-13-10 8:17 PM
To: James Gould; James Mitchell; EPP Provreg
Subject: RE: [ietf-provreg] secDNS-1.1: use of only one form of interface

James, thanks for taking the time to respond,

Unfortunately your generalised case doesn't hold here. Consider TLDs that
are sub-divided into 2LDs (in this case as .au is). The 'policy' for gov.au
names is set by the government and very different to the 'policy' for the
commercial namespace com.au which is set by an industry body. In fact I
would argue that the 'general' case of one registry mapping to only one
'zone of registration' is actually the minority (you guys have com and net
in the same Registry don't you?), and with the pending release of new gTLDs
and the industry trend towards separation of 'registry service providers'
from 'registries' having multiple zones of registration in one registry is
only going to increasingly become the norm.

Putting that aside, you site domain transfer as the reason for enforcing
'consistency', if the rule where that a consistent method should be used for
all domains residing in one 'zone' such consistency is still maintained, as
the expected behaviour is still predictable by clients based on the zone of
the domain (which would determine the policy that applies). We have much
cross-zone inconsistency like this in Registries already that the protocol
doesn't dictate, I mean, control ( :P ) (e.g. In some zones, technical
contacts are mandatory and in others they are not) and Registrars cope
perfectly fine with this 'complexity'. Isn't this the reason for the 2306
and 2308 error codes?

Even then, programmatically determining which method is in use by a domain
is not that difficult anyway (no more difficult than say doing an 'info'
command and checking the results ;) ) and most Registries wrap all this
'complexity' up in toolkits anyway (none of our Registrars implemented EPP
themselves, they all just use our toolkits).

As for the host attributes vs. host objects decision, unfortunately we
weren't paying as much attention to this group back then as we should have
been, as a similar rationale could be applied.

For now we will just need to have a non-conforming implementation, as I'm
hardly going to run separate Registries just for this tiny DS/key data
difference. We were just concerned that there was some more serious
rationale that we hadn't thought of, luckily not.

Thanks

Chris Wright
Chief Technology Officer
AusRegistry Pty Ltd

From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] On
Behalf Of James Gould
Sent: Monday, 13 September 2010 11:39 PM
To: James Mitchell; EPP Provreg
Subject: Re: [ietf-provreg] secDNS-1.1: use of only one form of interface

James,

> We have one server (process) that provides an EPP interface for more
> than one zone, each zone potentially having a different policy, i.e. one
> policy may mandate Key Data whereas another policy may mandate DS Data.
> Furthermore, I do not understand why one zone cannot have a policy that
> gives registrants the choice of DS Data or Key Data for a domain. What
> is the rationale for this requirement?

I don't understand what you mean by "each zone potentially having a
different policy".  Generally the Registry is providing an EPP interface for
the management of a TLD (zone) with a single server-side policy.  The
rationale for requiring one form of interface for a server was the
following:
1. Be consistent with the other EPP specifications.  RFC 5731 supports two
forms of interfaces for name servers (hostObj and hostAttr) where "A server
operator MUST use one name server specification form consistently".   
2. Provides for a simpler and cleaner interface if the server instance only
supports a single interface for the same object types (DS in RFC 5910).
  With the DS Data Interface the client is responsible for managing the DS
and with the Key Data Interface the server is responsible for managing the
DS based on the Key Data.  Mixing both interfaces will make it more complex
for clients, since all clients would have to support both interfaces and
would need to determine the interface to use on domain transfers.  



-- 


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: James Mitchell <james.mitchell@ausregistry.com.au>
Date: Sat, 11 Sep 2010 03:11:29 -0400
To: EPP Provreg <ietf-provreg@cafax.se>
Subject: [ietf-provreg] secDNS-1.1: use of only one form of interface

Hello,

I am seeking clarification on the following sentence from RFC 5910.

   The server MUST support the
   use of only one form of interface across all <secDNS:create>,
   <secDNS:update>, and <secDNS:infData> elements, except during a
   transition period, during which the server MAY support both.

We have one server (process) that provides an EPP interface for more
than one zone, each zone potentially having a different policy, i.e. one
policy may mandate Key Data whereas another policy may mandate DS Data.
Furthermore, I do not understand why one zone cannot have a policy that
gives registrants the choice of DS Data or Key Data for a domain. What
is the rationale for this requirement?

Regards,

James Mitchell

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se



-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se