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

[Andrew Sullivan <ajs@shinkuro.com>]

On Tue, Sep 14, 2010 at 10:16:44AM +1000, Chris Wright wrote:
> 
> 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.

It is somewhat unfortunate that the word "registry" has received some
new meaning over time.  We need to be careful here.

One meaning of "registry" (and, I think, its historical meaning, but I
don't think we need to determine that) is quite literal: "the
facility whereby registration in a zone happens".  The important
detail to note is that this meaning intimately ties the registry to
the zone over which it has administrative authority.

Another meaning, and one that seems to be gaining primacy, is the
collection of software and policies that control registration in one
or more zones.

These are subtly different.  I believe, however, that RFCs generally
rely on the first meaning.  I suspect this is why the RFCs in question
actually avoid the term "registry" in favour of "repository".  There
is no question that more than one repository can live inside a single
software system, and that therefore the policies governing each
repository could be different.  That said, the text as it stands
governs the _server_, rather than the repository, which is perhaps
somewhat more problematic.

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

Just as an aside, that is a poor argument in favour of the principle
that more complexity in the protocol is ok.  On the contrary, if the
number of actual implementations is small, you want a simpler protocol
with fewer options.  That's the way to ensure that poorly-tested
assumptions about the interaction of different options don't end up
biting someone later when they try to implement to the specification.
Remember, RFCs are about interoperability as much as anything else.

> For now we will just need to have a non-conforming implementation

Surely not.  You can just declare a transition period without a sunset
date.  Poof! you're conformant.

A


-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se