belated response to Re: Comments on overall direction

[Edward Lewis <lewis@tislabs.com>]

At 3:29 PM -0500 12/26/00, Karl Auerbach wrote:
>1. A nit: I'd like to get rid of this horrid "registrar", "registry",
>"registrant" terminology.

I think that changing this would be hard.  I haven't heard any other
comments on this, my observation is that the consensus would be to let the
terminology stand.

>3. I am very wary of continuing the current notion of agent-to-agent
>transfers.  To my mind any transfer should be accomplished via the
>customer, i.e. that some signed certificate must be handed by the
>relinquishing agent to the customer for the customer to hand over to the
>acquiring agent.

My concern would be an unresponsive relinquishing agent, perhaps a
registrar who has gone out of business, lost the ability to apply a trusted
digital signature, etc.  It seems reasonable that an organization might
have a domain registered for 2 years and not change it, only to find at
renewal time that the registrar who did the work as moved on.  The fact
that a registrar does not have (to have) face-to-face contact with the
customer makes it more likely that some "weaker" registrars may fade.  (The
analogy with the OS and capabilities - if I interpret it correctly doesn't
seem to hold - a process would die when the OS dies.)

>4. I'm nervous about the inclusion of fancy negotion protocols - such as

I am too, but on the other hand, I've had experience with protocols that
did no negotiation with too little feedback.  There was an event scheduling
protocol that wouldn't allow events that overlapped, not even by a second.
If a rejected request would have satisfied if delayed by just 1 second, you
wouldn't know.  (This was not an internet protocol.)

Just a comment...

>5. The issue of privacy and security seems to be being glossed over - we
>are talking about databases that will be among the worlds larger bodies of
>personally identifiable information - with both strong privacy
>characteristics and high value to marketing/sales folks.

While at this time I can neither dispute nor support the claim of a
"glossing over" of privacy and security, those issues will be something I
plan to watch.  In this working group we are confining ourselves to the
protocol, so the questions I will be looking to see answered are "can the
protocol support (appropriate) privacy and security?" and "will the
protocol hinder privacy and security?"

Of course, this is in addition to the regular questions such as "will the
protocol work?", etc.

I thought I might add that "confining ourselves to the protocol" does not
mean that documents will ignore other aspects (such as definitions of
terminology).

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

"It takes years of training to know when to do nothing" - Dogbert

Opinions expressed are property of my evil twin, not my employer.