[Ietf-not43] IRIS Open Issues
Paul Stahura
stahura at enom.com
Thu Nov 13 16:34:02 EST 2003
I believe ICANN requires the gaining registrar to obtain and store the
whois information it acquired before transfer, and also to store
all changes to the registrant name field. Not 100% sure on this last one,
but I know eNom keeps all changes.
I'm pretty sure NSI does too, which is how they (and not just them, I'm
using NSI as an example)
can send marketing emails to registrants that are no longer NSI customers
(even years afterward)
without looking up the whois (email addresses) in the gaining registrar's
whois.
-----Original Message-----
From: George Michaelson [mailto:ggm at apnic.net]
Sent: Thursday, November 13, 2003 11:28 AM
To: Ryan Lehning
Cc: ietf-not43 at lists.verisignlabs.com; David Blacka; Andrew Newton
Subject: Re: [Ietf-not43] IRIS Open Issues
On Thu, 13 Nov 2003 13:55:20 -0500 Ryan Lehning <rlehning at smimetlaw.com>
wrote:
> George, forgive the newbie question, can you defined "mandatory change
> logging?"
>
> Thanks,
> Ryan
if somebody changes a IP address block registry object, and its not
detailing
customer-specific records (which probably change a LOT, and are therefore
less
likely to be ameanable to tracking in depth, and in any case get to privacy
issues) then it should be required that you can find out the historical data
against that block.
so the change logging which currently in RPSL/RIPE WHOIS V.3 can be deleted
at
the maintainers request (its just a field in the block, and can be added or
removed at will) would become readonly/append mode. A growing list of dates
at
which changes were made.
This is not a policy requirement, its a loose proposal which might become a
policy requirement.
-George
>
> -----Original Message-----
> From: George Michaelson [mailto:ggm at apnic.net]
> Sent: Thursday, November 13, 2003 12:55 PM
> To: Andrew Newton
> Cc: David Blacka; ietf-not43 at lists.verisignlabs.com
> Subject: Re: [Ietf-not43] IRIS Open Issues
>
>
> On Thu, 13 Nov 2003 12:08:21 -0500 Andrew Newton <andy at hxr.us> wrote:
>
> > David Blacka wrote:
> > >
> > > Nothing else in CRISP has pointed toward using it to see historical
data
>
> > > about a registration object. I would be somewhat reluctant to start
> with
> > > this.
> >
> > Agreed. I'm just throwing it out as a possible thing that could be done
> > due to this change. I'm not convinced of its usefulness.
>
> In number registry space, it might help with people tracking potential
> hijacked
> nets. We're considering some issues around mandatory change logging on top
> level
> objects. Equally, this can be done offline, its more about information
> management than lookup.
>
> I think I have some problems conceptualizing what 'sort' means in some of
> these
> contexts. If you mean 'by time' then the sort isn't on the status, its on
> the
> date of the status. If there are other more complex sort orders, why isn't
> that
> being done in the client?
>
> -George
> _______________________________________________
> Ietf-not43 mailing list
> Ietf-not43 at lists.verisignlabs.com
> https://lists.verisignlabs.com/mailman/listinfo/ietf-not43
--
George Michaelson | APNIC
Email: ggm at apnic.net | PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490 | Australia
Fax: +61 7 3367 0482 | http://www.apnic.net
_______________________________________________
Ietf-not43 mailing list
Ietf-not43 at lists.verisignlabs.com
https://lists.verisignlabs.com/mailman/listinfo/ietf-not43
More information about the Ietf-not43
mailing list