RE: [Ietf-not43] Re: Last-Verified Date Contact Element

["Liu, Hong" <Hong.Liu@neustar.biz>]

Rick,

I have similar concerns. I still don't know what this new element is for and
how it is going to be used.

I specifically quote Eric's email as important to note:

"It is true these elements are managed by the registry, but they are done so
in response to client-initiated events."

In particular, without getting a clear explanation on what "verification"
means, I assume that it is the registrars' responsibility to do whatever
"verification" required, since it is the registrars that interface with the
registrants.

I don't mean to bring policy issues into this discussion. I just don't know
if we can address this issue in a vacuum.

--Hong

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:brunner@nic-naa.net]
Sent: Sunday, October 27, 2002 9:29 AM
To: Rick Wesson
Cc: Eric Brunner-Williams in Portland Maine; shollenbeck@verisign.com;
'ietf-provreg@cafax.se'; ietf-not43@lists.verisignlabs.com;
iesg@ietf.org; brunner@nic-naa.net
Subject: [Ietf-not43] Re: Last-Verified Date Contact Element


Rick,

I asked:

> > What prevents a client providing some authInfo from also attempting to
set
> > upID and set or modify upDate?

You replied:

> the updated date and last-modified date are managed by the registry.

Here's what I ment:

The <contact:upID> is an <info> response element that contains the
identifier
of the client that last updated the contact object. The <contact:clID>
element
that contains the identifier of the sponsoring client. This client has the
valid authInfo, and can perform an <update> on the contact object in
question.
If that client wants to date-stamp/touch a client object for the purpose of
associating some temporal identifier to "verification" (and I still don't
know wha that means), isn't this the recipie? This either sets or modifies
the <contact:upID> and sets or modifies the <contact:upDate>.

It is true these elements are managed by the registry, but they are done so
in response to client-initiated events.

I guess I'm still in the dark about the mechanism, as well as the purpose,
and utility.

Color me clueless,
Eric
_______________________________________________
Ietf-not43 mailing list
Ietf-not43@lists.verisignlabs.com
http://lists.verisignlabs.com/mailman/listinfo/ietf-not43