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


To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
CC: "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
From: Klaus Malorny <Klaus.Malorny@knipp.de>
Date: Tue, 19 Jun 2001 11:16:07 +0200
Sender: owner-ietf-provreg@cafax.se
Subject: Re: Poll response data

"Hollenbeck, Scott" wrote:
> 
> Dan,
> 
> Echoing what Rick said, I believe that the types of informational messages
> that should be made available via a <poll> are a matter of registry policy,
> so that's why there isn't a detailed description of the messages that may be
> supported.  I also believe that some situations should be relayed to a
> client via messages that can be polled, and others should be relayed to a
> client via offline reporting.  Those situations that require timely client
> protocol action, such as any object transfer or upcoming object expiration,
> should be relayed to the client via the polling mechanism.  Purely
> informational notices that don't have temporal factors may be better left to
> some kind of registry reporting service.
> 
> I'm sure I can make the text more clear to make this intent more obvious.
> 
> <Scott/>


Hi Scott,

sorry, I have to disagree. Since the transfer of objects is an integral part
of your protocol, it is a kind of incompleteness if the mechanisms which are
used to notify the losing registrar are not described. You describe in detail
when the gaining or losing registrar may request/cancel/reject/approve a
transfer, but not the exact way of the notification, although this is similar
essential to the transfer process as the other stuff. Since you already
limited the freedom of a registry's policy* (e.g. the object model/fields, the
relation between hosts and domains, the way that objects are transferred), I
don't see any problems in defining a message returned on a poll that contains
at least the following information: the object which is requested to be
transferred, the registrar who wants to gain the object, an expire date that
tells the losing registrar if/when a default action is taken and what this
default action is (approval or rejection).



* this is, of course, not an accusation. Anyone who defines a protocol has to
fix things and thus limiting the degree of freedom.

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