Comments on overall direction

[Karl Auerbach <karl@CaveBear.com>]

I've just read through the e-mail that came in over the last week.

What struck me is how much it seems tied to existing practices of NSI's
registry.  For example, just because NSI today has registrations in year
units is no reason to think that that must be true for everyone
everywhere.

And what struck me further is how quickly the discussion focused on domain
name registration and forgot that there are other kinds of network
resources that need similar services.

So -- my comments:

1. A nit: I'd like to get rid of this horrid "registrar", "registry",
"registrant" terminology.  There have been more instances than I can count
where discussions went off into the weeds because somebody accidently used
the wrong ending to the string "registr".  Mike O'Dell has suggested
"repository" and "agent" in lieu of "registry" and "registrar".
Personally I like the trio "database", "agent", and "customer".

2. There are many kinds of Internet resources that customers will want to
lay claim to - domain names, IP address blocks, and ASNs come to mind as
some we have today.  The common feature about these is that they can all
be described using the following skeletal paradigm:  (The following is for
illustration, I'm aware that there are more detailed versions.)

        <registration-object>
         <definition-of-thing-being-registered>
           ...
         </definition-of-thing-being-registered>
         <duration-of-registration-info>
           ...
         </duration-of-registration-info>
         <contact-list>
          <admin-contact>
            <contact-info>
               ...
            <contact-info>
          </admin-contact>
          <tech-contact>
            <contact-info>
               ...
            <contact-info>
          </tech-contact>
          <billing-contact>
            <contact-info>
               ...
            <contact-info>
          </billing-contact>
         </contact-list>
        </registration-object>

This suggests several things to me:

   - That we can have a single protocol to handle registrations of all
     kinds of things, not just DNS names.

   - That there is no reason why this package can't also be used between
     all parties to this system - agents-to-database (and
     vice-versa), customers to agents, agents-to-agents,
     databases-to-escrow systems, agents-to-escrow systems.

   - That the protocol should be designed in "chunks".  Thus one chunk
     would support a lockable registration exchange between a customer and
     its selected agent, and also between an agent and the database.  And
     another chunk of protocol would support unlocked query access.  (This
     latter function happens to be a nice alternative to the underdefined
     port 43 mechanism.)

3. I am very wary of continuing the current notion of agent-to-agent
transfers.  To my mind any transfer should be accomplished via the
customer, i.e. that some signed certificate must be handed by the
relinquishing agent to the customer for the customer to hand over to the
acquiring agent.

4. I'm nervous about the inclusion of fancy negotion protocols - such as
have been aluded to with regard to the negotion of expiration timestamps.
My own preference is that the protocols simply have a code to express that
a request has been "rejected due to unacceptable expiration timestamp".
To my mind external channels should be used to convey policies about these
kinds of things.

5. The issue of privacy and security seems to be being glossed over - we
are talking about databases that will be among the worlds larger bodies of
personally identifiable information - with both strong privacy
characteristics and high value to marketing/sales folks.

This suggests to me that there ought to be adequate information in the
protocols to build unambiguous, timestamped, transaction journals.

It also suggests to me that there be provision for solid identification
and authenticatation of all transactions.  I don't care whether this comes
as part of this protocol or as part of a lower layer protocol.  However,
since we are going to have to abide by inconsistant privacy laws I have
this more than sneaking suspicion that implementations are going to have
to resort to call-outs to policy servers - as such we ought to make sure
that these protocols and data representations are amenible to being
filtered by some sort of policy expressions that might come back from such
policy servers.

           --karl--