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