To:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
cc:
George Belotsky <george@register.com>, <ietf-provreg@cafax.se>, <ietf-whois@imc.org>
From:
Karl Auerbach <karl@CaveBear.com>
Date:
Tue, 23 Jan 2001 12:38:50 -0800 (PST)
In-Reply-To:
<200101222311.f0MNBZn03650@nic-naa.net>
Reply-To:
Karl Auerbach <karl@CaveBear.com>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: Merging RRP and Whois
My own feeling is different. I consider that any reasonable registrar-registry mechanism needs contain mechanisms by which one asks for the existing registration state. In the RRP case, that query mechanism is pretty much registrar asking/registry responding. And since we've got to leave the door open to IPv6 and other kinds of data, the data representation needs to be exensible. It seems to me that it is only a matter of using that extensibility to make that same mechanism work so that a client/customer may ask a status question of a registry or registrar. The larger issues to me are those of a) identification/authentication of the parties and b) authorization and privacy. I'd like to think that we could be clever enough to invent mechanisms that would handle both sitations - registrar as status querier and customer as status querier. It seems to me that much of the issue of authorization and privacy can be handled by having server implementations call out out policy servers much as we are starting to do for configuration, QoS, and capacity provisioning. My sense is that if one comes up with a well structured data representation for the queries and responses that one can come up with a policy definition structure that meshes. The biggest issue - that of identification/authentication of both the querier and the responder are, to my mind, the biggest ones. In the RRP situation we have a limited set of players making it possible to simply use sneakernet techniques to get id/auth data to the various participants. --karl--