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

[Theo Kramer <theo@flame.co.za>]

On 14 Sep 2010, at 06:53AM, Michael Young wrote:

> 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

-- 
Regards
Theo


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