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


To: "'Klaus Malorny'" <Klaus.Malorny@knipp.de>, ietf-provreg@cafax.se
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Fri, 5 Jan 2001 07:11:24 -0500
Sender: owner-ietf-provreg@cafax.se
Subject: RE: hello and some initial comments

Klaus,

Thanks for the comments.  If you believe they reflect something that you'd
like to see changed in the requirements draft, would you please identify the
section of the draft that you think needs to be changed and the change that
you'd like to see made?

<Scott/>

-----Original Message-----
From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de]
Sent: Friday, January 05, 2001 3:47 AM
To: ietf-provreg@cafax.se
Subject: hello and some initial comments




Hello,

first of all, I want to say hello and to introduce myself briefly. I am
working
as a software developer for Knipp Medien und Kommunikation GmbH, which is
(beside others) in the domain name registration business. Having the
imagination
of a simple but versatile domain registration protocol which is adopted by
most
domain registries around the world and which eases the registration
business, I
joined the list in the hope to contribute a little bit to reach this goal.


I saw that the discussion is already active for about two weeks;
unfortunately,
I had no time to read all postings in the archive. I promise that I will do
it,
but for now, I would like to make some general comments I prepared some days
ago, 
based on Scott Hollenbeck's drafts and my own thoughts. Please excuse if 
I mention topics which have already been addressed or are currently in
discussion.


Low Level Protocol Issues
-------------------------

I saw some discussions about the underlying communication protocol. I
support
the idea of using one of the existing/emerging protocols, like BXXP instead
of
re-inventing one.


High Level Protocol Issues
--------------------------

As I understand, the client/registrar and the server/registry interact by a
request/response model. In this context, I think it is very important to
have
some kind of server initiated interaction (even if done by a polling
mechanism).
In some cases, e.g. the transfer of domains between registrars, the
client/registrar needs to be informed asynchronously. In current
registration
systems, this is mostly done outside of the core protocol, e.g. by sending
e-mails. This should be integrated into the protocol, both for
simplification
and to benefit from other protocol features, like transaction management,
encryption.


Transaction Management
----------------------

The protocol must be able to deal with errornous states, like interruption
of
the communication between the two endpoints. So the protocol should
incorporate
a transaction management. It should be separated from the design of the
requests, in contrast to the way the problem was solved in the RRP: Here the
commands were designed in a way to allow the client to repeat any command
which
it thinks the server might not have executed. Eventually, this may limit the
possibilities of the commands. For example, the "renew" command had to be
extended beyond to its straight forward design to avoid an unwanted
extension of
the registration period in the case of a command repetition.


Internationalization/Localization
---------------------------------

Although the protocol must of course support internationalized data, e.g.
Unicode domain names or contact data, it is IMHO not required for the
protocol
to support multiple languages itself, e.g. to generate error messages in
different languages. It is more important to make them machine
understandable
;-), e.g. to list related information separately and identifiable. It is the
registrar's duty to generate a message suitable for human beings in whatever
language
out of it, if the registrar feels the need to (see also below)


Modularisation - Object Model
-----------------------------

To have a modular concept may be an advantage -- it may be useful for
registries
which require additional data or policies. If we introduce a concept of
abstract
objects, with different concrete object types varying from application to
application,

- we need an object model which describes what properties an object can have
and
how an object can interact with other objects

- the protocol must enable the client to get information about the existing
object types and the effect of operations on them (meta information)

- the protocol must not only enable the client to get the information about
a
single object, but also the relation of it to other objects.

To give two examples: a query of a domain object should not only report the
contacts and name servers used by the domain, but also dependencies which
are
hidden in current systems, e.g. name servers which lie in zone of the domain
or
domains which use a certain contact.

If a registrar attempts to transfer a (domain) object, it needs to know
whether
it also gets the name servers lying in the domain's zone and which they are.


Object Ownership
----------------

It must be defined how objects appear in a multi-registrar/-client
environment.
Are objects owned by one client visible to others, can they be used by
others?
What happens on ownership transfers, esp. with related objects? Are they
cloned?


Modularisation - Error Reporting
--------------------------------

In case of a modular concept, the error reporting mechanism must have some
kind
of flexibility, as operations on different object types may produce
different
errors. In general, I propose some kind of classification system, at least
in
the following classes

- protocol violations (e.g. bad commands, missing parameters)

- integrity violations (e.g. trying to delete a name server object which
still
in use by a domain object)

- policy violations (the command is technically correct, but violates a
registry
policy, e.g. modify a domain which is on-hold)


Renewal
-------

Models different to NSI/Verisign model should be supported, esp. shorter
periods
and auto-renewal.



regards,

Klaus Malorny


___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     Klaus.Malorny@knipp.de             Tel. +49 231 9703 0

Home | Date list | Subject list