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-