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


To: "'Edward Lewis'" <lewis@tislabs.com>, ietf-provreg@cafax.se
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Tue, 30 Oct 2001 11:10:37 -0500
Sender: owner-ietf-provreg@cafax.se
Subject: RE: Registrar-registrar notification

> -----Original Message-----
> From: Edward Lewis [mailto:lewis@tislabs.com]
> Sent: Tuesday, October 30, 2001 10:22 AM
> To: ietf-provreg@cafax.se
> Cc: lewis@tislabs.com
> Subject: Registrar-registrar notification
> 
> 
> When reading through the drafts, the following dilemma 
> appears to be possible.
> 
> Reg A registers domain1.example, with ns1.domain1.example as the name
> server.  (I'm using just one server here for simplicity.)
> 
> Reg B has a customer arrive that wants domain2.example and use
> ns2.domain1.example as its name server.
> 
> Reg B's problem is that it needs Reg A to cooperate and create
> ns2.domain.example before B can proceed fulfilling the order.  The two
> questions here are 1) what is there to motivate A to cooperate <not a
> provreg question> and 2) how does B request A to make the change <assuming
> no hostility>.

I've long maintained that the proper behavior here would be for the customer
to create ns2.domain1.example through the registrar that manages
domain1.example.  I can't imagine a registrar wanting to create name servers
(or any other object) because another registrar wants them to.  As a domain
name registrant, I wouldn't want my registrar of choice to create anything
that falls into the domain1.example name space unless they do it on my
authority.

> The answer to 2 is either a simple call from B to A, or possibly a message
> sent via the registry (and picked up by A via polling or pushing).
> 
> The question to the group: should the protocol define such a notification
> schema/object/message?  If so, perhaps the means are already in the drafts
> - should the drafts discuss the general issue here.
> 
> BTW - the same issue rises when Reg A tries to remove domain1.example.
> ns2.domain1.example is serving domain2.example, so A needs B to break that
> bond first.

This, I think, is the more reasonable scenario.  An existing object
relationship prevents a delete from happening, and some other client has to
break the relationship to make things work.

It would be quite possible for the server to send a pushed/pulled message to
both clients when an operation fails because of an existing object
relationship.  Both clients thus become aware of what needs to change, and
they can work out the details offline.  It would be fairly straight-forward
to add text to the <delete> description to suggest that messages SHOULD be
exchanged in this situation.

I'd prefer to stay far away from any sort of direct registrar-registrar
IM-like services.  Not all registrars will be running the same sort of
clients, and I can see how such exchanges could very well contribute to
accidental or purposeful flooding attacks.

-Scott-

Home | Date list | Subject list