Subject: [Ietf-not43] IRIS Open Issues

From: stahura at enom.com (Paul Stahura)
Date: Thu Nov 13 16:33:45 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:[email-masked]] 
Sent: Thursday, November 13, 2003 11:28 AM
To: Ryan Lehning
Cc: [email-masked]; David Blacka; Andrew Newton
Subject: Re: [Ietf-not43] IRIS Open Issues

On Thu, 13 Nov 2003 13:55:20 -0500 Ryan Lehning <[email-masked]>
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:[email-masked]]
> Sent: Thursday, November 13, 2003 12:55 PM
> To: Andrew Newton
> Cc: David Blacka; [email-masked]
> Subject: Re: [Ietf-not43] IRIS Open Issues
> 
> 
> On Thu, 13 Nov 2003 12:08:21 -0500 Andrew Newton <[email-masked]> 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
> [email-masked]
> https://lists.verisignlabs.com/mailman/listinfo/ietf-not43

-- 
George Michaelson       |  APNIC
Email: [email-masked]    |  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
[email-masked]
https://lists.verisignlabs.com/mailman/listinfo/ietf-not43

---

From: sanz at denic.de (Marcos Sanz/Denic)
Date: Thu Nov 13 21:28:12 2003

> but I know eNom keeps all changes.

The registry I work for keeps *lots* of things, however doesn't make them 
available via 43

Regards,
Marcos

---

From: jaap at sidn.nl (Jaap Akkerhuis)
Date: Thu Nov 13 21:50:10 2003

The same for mine, and not because ICANN wants it. Furthermore,
there are privacy regulation which disallow us to publish this data.
Most of the times it requires court orders.

Anyway, this all is policy. As I have always understand it, the
CRISP effort tries to be give to define a set of tools which can
be used under various different policy regimes.

	jaap