To:
"Hollenbeck, Scott" <shollenbeck@verisign.com>
Cc:
"'Edward Lewis'" <edlewis@arin.net>, ietf-provreg@cafax.se
From:
Joe Abley <jabley@isc.org>
Date:
Wed, 8 Jan 2003 12:33:36 -0500
In-Reply-To:
<3CD14E451751BD42BA48AAA50B07BAD6033704CC@vsvapostal3.prod.netsol.com>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: privacy
On Wednesday, Jan 8, 2003, at 12:21 Canada/Eastern, Hollenbeck, Scott wrote: >> Would it be possible to hear the set of requirements to which the >> attribute solution forms an acceptable solution? > > The requirements as discussed between myself, the chairs, and the > interested > IESG members have been sent to the mailing list at least three times: > > http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00041.html > > http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00100.html > > http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00004.html > > One can argue that these messages aren't exactly a formal requirements > specification, but this is what we've been working with. Hmm, the only part of those I can see that looks like a requirements analysis is this: > What IESG want is _some_ mandatory to implement mechanism which makes > it possible for the registrar to say to the registry "Do not disclose > this attribute to a third party". If the wg want to have the mandatory > to implement mechanism more powerful than that, fine. What is not ok is > the protocol not having any mandatory to implement privacy mechanism in > it, only extensions. The rest is discussion about possible solutions. If that's all the requirements analysis there is, then I think the chances of coming up with an implementation that will be actually useful to registries are rather slim. For example, I had assumed that the attributes proposal would at least meet the requirements of gTLD registries, since you raised it, but Rick's comments earlier seem to suggest otherwise. Is there *any* registry you know of for whom the attributes proposal is comnpatible with an existing privacy policy? The needs of registries seem like a good starting point for this, wherever this work is done (assuming it is done). Starting out with an implementation and working back to see how it can be shoe-horned into registries seems like a waste of time: regardless of how mandatory these attributes are made in the draft spec, if they don't fit, registries won't use them. Joe